BridgeGate is Vorro’s proprietary EiPaaS platform made for complex healthcare data integrations.
BridgeGate is Vorro’s proprietary EiPaaS platform made for complex healthcare data integrations.
Some versions of Windows will automatically add folders to a Quick Access section in File Explorer. Any folders that exist in Quick Access, that exist under the BridgeGate folder, will cause the Upgrade to fail because it will not be able to rename the BridgeGate folder. If your upgrade fails, go to File Explorer and under the Quick Access section remove any folders that are child folders of the BridgeGate folder.
BridgeGate Web Service enabled as a service supports User/Password in the SOAP Header.
Authentication : This specifies whether Authentication should be performed and if so what type. NONE : No authentication will be performed by this BridgeGate Web Service.
BASIC : Choosing BASIC will reveal inputs for user name and password. These values will be stored in the workflow for comparison against values provided in the request as follows: (Note: do not confuse BASIC with “Authorization: Basic” BASIC in this scope is referring to the username / password being provided in the workflow) The BridgeGate Web service will use the inbound SOAP header to identify the username and password to use for authentication.
BridgeGate will look for 'Username' and 'Password' in the SOAP header. Example of Soap Header <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://mytest.bridgegateintl.com/websvcs/usertopersonservice/xsd"> <soapenv:Header> <Username>admin</Username> <Password>YWRtaW4=</Password> </soapenv:Header> <soapenv:Body> <xsd:Root> <xsd:User> <xsd:Age>23</xsd:Age> </xsd:User> </xsd:Root> </soapenv:Body> </soapenv:Envelope>
The Username field is assumed to be plain text.
The Password field is assumed to be base64 encoded.
BRIDGEGATE : The BridgeGate Web Service will authenticate the values provided in the request against the BridgeGate Users as follows: The BridgeGate Web service will use the inbound SOAP header to identify the username and password to use for authentication.
BridgeGate will look for ‘Username’ and ‘Password’ in the SOAP header. (See above example)
The Username field is assumed to be plain text.
The Password field is assumed to be base64 encoded.
The username and password will be authenticated against the BridgeGate Users and the Users must have BridgeGate Web Service portal permissions.
Failed Authentication : Results in an AXIS Fault being returned with faultcode of “401” and faultstring of “Authentication failed : Username or Password is incorrect or User does not have security rights”. Either correct the Username and/or Password and resend your request or if doing BRIDGEGATE Authentication confirm that the user has the “BridgeGate Web Service” protocol permission.
The BridgeGate Portal Login page has a link “Forgot your password?” This link will prompt for the users email and if the email entered is the same on file for the user will send an email that allows the user to reset their password.
The email includes a link to the public URL of the portal. The External link URL can be set by updating the bridgegate.xml setting below.
<SERVER_CONFIG EXTERNAL_URL=”https://myexternaldomain.com” ….. />
Below are examples of xpath that can be used to search for data in an xml document. When using the replacement feature the xpath will be the search and what is found will be replaced.
Example: Get all names of employees over 35 XPATH: /Employees/Employee[age>35]/name
Get Employee id 2 XPATH: /Employees/Employee[@id=’2′]/name
Get all Employees with a gener of Female XPATH: /Employees/Employee[gender=’Female’]/name
The XML Data:
<?xml version="1.0" encoding="UTF-8"?> <Employees> <Employee id="1"> <age>29</age> <name>Pankaj</name> <gender>Male</gender> <role>Java Developer</role> </Employee> <Employee id="2"> <age>35</age> <name>Lisa</name> <gender>Female</gender> <role>CEO</role> </Employee> <Employee id="3"> <age>40</age> <name>Tom</name> <gender>Male</gender> <role>Manager</role> </Employee> <Employee id="4"> <age>25</age> <name>Meghan</name> <gender>Female</gender> <role>Manager</role> </Employee> </Employees>
CCD Example: Get the ClinicalDocument title XPATH: /ClinicalDocument/title
Get the root attribute of the PatientRole ID XPATH: /ClinicalDocument/recordTarget/patientRole/id/@root
Get the extension of the patientRole where the id root attribute equals 2.16.999.1.113883.3.3388.1.1.1.999999.9 XPATH: /ClinicalDocument/recordTarget/patientRole/id[@root=’2.16.999.1.113883.3.3388.1.1.1.999999.9′]/@extension
<?xml version="1.0"?> <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:fn="http://www.w3.org/2005/xpath-functions" xmlns:sdtc="urn:hl7-org:sdtc" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <realmCode code="US"/> <typeId extension="POCD_HD000044" root="2.16.840.1.9999.1.3"/> <templateId root="2.16.840.1.113883.10.20.22.1.1"/> <templateId extension="2015-08-01" root="2.16.840.1.9999.1.3"/> <id extension="b386510e-01b1-45c0-b25b-d5hs58h4" root="2.16.840.1.113883.3.3388.1.1.1.99999"/> <code code="34133-9" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Summarization of episode note"/> <title>Clinical Summary</title> <effectiveTime value="20180828141840"/> <confidentialityCode code="R" codeSystem="2.16.840.1.113883.5.25" codeSystemName="Confidentiality" displayName="Restricted"/> <languageCode code="en-US"/> <recordTarget> <patientRole> <id extension="98C6B689-7E5B-44CF-87ED-A6BC4709419C" root="2.16.999.1.113883.3.3388.1.1.1.888888.9"/> <id extension="PYCT-L94-RHFC" root="2.16.999.1.113883.3.3388.1.1.1.999999.9"/> ....
For more information on the XPath Syntax goto https://www.w3schools.com/xml/xpath_intro.asp
BridgeGate uses a configurable polling setting in the BridgeGate.xml to control how often the File RTP service will poll. The default value is 20 seconds. To modify the default value, go to the BridgeGate.xml and change the following element:
<FILE WATCHER_SVC_RATE=”20000″/>
Our clients Authenticate and execute BridgeGateHTTP workflows using the Portal User Name and Password (over HTTPS ) two different ways.
First, and less common, they include the respectful key/value pairs in the URL &userName=[USER]&password=[PWD].
Second, they include HTTP header values as seen in the screen shot below.
The portal user must have BridgeGateHTTP Protocol security set. If the Get Data is set to ‘Authenticate’ checked, it will require the Portal username/password. If Authenticate is not checked, it will execute the workflow with no portal login validation.
If the BridgeGateHTTP workflow is set to authenticate and the credentials are not included, incorrect, or does not have the appropriate security permissions (BridgeGateHTTP) the client will receive a 403 error.
HTTP Status 403 – Authentication Credentials not found
HTTP Status 403 – Incorrect Login and/or Password
*******************************************
Importing a P12 (i.e.: PKCS12) Certificate Chain into a BridgeGate Java KeyStore (JKS)
*******************************************
Keytool path: C:\bridgegate\java\bin\keytool.exe
Openssl path: C:\bridgegate\utils\openssl\openssl.exe
P12 Certificate Chain: C:\data\cert\Bridgegate_HUBCertificates.p12
BG Staging JSK KeyStore: C:\data\cert\bridgegate.jks
*** Note: The Alias used in the JKS does not need to match the Common Name (CN) of the Client System Key. The more important thing is that the BridgeGate Java KeyStore (JKS) does not contain duplicate aliases. ***
1) List and verify P12 Certificate Chain contents:
c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\data\cert\Bridgegate_HUBCertificates.p12
Enter keystore password:
***************** WARNING WARNING WARNING *****************
* The integrity of the information stored in your keystore *
* has NOT been verified! In order to verify its integrity, *
* you must provide your keystore password. *
***************** WARNING WARNING WARNING *****************
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
Alias name: Bridgegate_HUB
Creation date: Jul 11, 2014
Entry type: SecretKeyEntry
2) IF the P12 Certificate Chain file is not password locked, you will need to recreate is with a password:
*** Export you current certificate to a password less pem type. Note: Leave the ‘Import Password’ field empty in this step.
c:\bridgegate\utils\openssl>openssl pkcs12 -in C:\data\cert\Bridgegate_HUBCertificates.p12 -out C:\data\cert\export.tmp.pem -nodes
Enter Import Password:
MAC verified OK
*** Convert the password less pem to a new pfx file with password:
C:\bridgegate\utils\openssl>openssl pkcs12 -export -in C:\data\cert\export.tmp.pem -out C:\data\cert\Bridgegate_HUBCertificates.locked.p12 -name “Bridgegate_HUB”
Loading ‘screen’ into random state – done
Enter Export Password:
Verifying – Enter Export Password:
3) Confirm Alias name is new password locked P12 Certificate Chain. Step 2 creates alias based on -name argument, if this is left out, the alias name can be “1”.
*** Confirm Chain length of 3 and the Owner/Issuer of each Certificate are in the proper order. ****
c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\data\cert\Bridgegate_HUBCertificates.locked.p12
Enter keystore password: ******
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
Alias name: bridgegate_hub
Creation date: Jul 14, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=Bridgegate_HUB ClientSystem, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
.
Certificate[2]:
Owner: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
.
Certificate[3]:
Owner: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
4) Import the P12 Certificate Chain into your BridgeGate Java KeyStore (JKS).
**** Note: You can alter the Alias name with the -alias and -destalias arguments. ****
c:\bridgegate\java\bin>keytool -importkeystore -destkeystore C:\data\cert\bridgegate.jks -srckeystore C:\data\cert\Bridgegate_HUBCertificates.locked.p12-srcstoretype PKCS12
Enter destination keystore password:
Enter source keystore password:
Entry for alias Bridgegate_HUB successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled
5) Verify the JKS contains the new Certificate under the correct Alias.
*** WARNING: This password field is displayed on screen as clear text! ***
c:\bridgegate\java\bin>keytool -v -list -storetype jks -keystore C:\data\cert\bridgegate.jks > c:\data\cert\out.txt
Enter keystore password: *********
While BridgeGate is logging transaction/workflow details to the database, if it experiences issues saving a SQL statement to the database the statements are saved in the following location and will be automatically retried every 20 minutes.
/bridgegate/server/sqlqueue.history
Using Hazelcast.xml for TCP-IP configuration: Set the CONFIG_FILE attribute value to the hazelcast.xml file.
The BridgeGate cluster is configured through the BRIDGEGATE_CLUSTER tag in the bridgegate.xml file.
CONFIG_FILE This attribute is not included by default and is not necessary. Hazelcast will use multicast by default. If TCP-IP needs to be enabled or additional configuration needs to be made ( like giving specific ip-addresses for different nodes ), this setting could be used. The value of this attribute should be the file path to hazelcast.xml . Example <BRIDGEGATE_CLUSTER BIND=”172.31.*.*” CONFIG_FILE=”/bridgegate/conf/hazelcast.xml” …. /> The sample hazelcast.xml file is below
<hazelcast xsi:schemaLocation="http://www.hazelcast.com/schema/config hazelcast-config-3.6.xsd" xmlns="http://www.hazelcast.com/schema/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <network> <port auto-increment="false">5701</port> <join> <multicast enabled="false"></multicast> <tcp-ip enabled="true"> <interface>10.0.0.30</interface> <interface>10.0.1.10</interface> </tcp-ip> </join> </network> </hazelcast> or <hazelcast xsi:schemaLocation="http://www.hazelcast.com/schema/config hazelcast-config-3.6.xsd" xmlns="http://www.hazelcast.com/schema/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <network> <port auto-increment="false">5701</port> <join> <multicast enabled="false"></multicast> <tcp-ip enabled="true"> <interface>10.0.0.30-40</interface> <interface>10.0.1.1-10</interface> <interface>10.0.2.1-10</interface> </tcp-ip> </join> </network> </hazelcast>
Multicast configuration for clustering auto-discovery is defined as:
<multicast enabled="true">
<multicast-group>224.2.2.3</multicast-group>
<multicast-port>54327</multicast-port>
</multicast>
To Turn on logging for BridgeGate clustering, this can be done from the Server Management Page and Server Log Tab inside it, from the BridgeGate portal.
Alternately, edit the file conf/log4j.xml file in the BridgeGate Home. Locate the element category with attribute name com.hazelcast. The priority value can be changed from OFF to INFO or DEBUG. Verify the bridgegate\bin\bg_service.conf contains the following -D options
wrapper.java.additional.26=-Dhazelcast.logging.type=slf4j
Or on Linux make sure the /bridgegate/bin/runbridgegate has the following JAVA Opt
JAVA_OPTS=”${JAVA_OPTS}-Dhazelcast.logging.type=slf4j”
<category name="com.hazelcast">
<priority value="OFF"/>
<appender-ref ref="HAZELCAST" />
</category>
If the Scaling of text and other items is too high(see image below) it will cause the Workbench to display labels incorrectly. To fix this go to the following in Windows 10 and change the value to 100%:
Display Settings/Advanced Display Settings/Advanced sizing of text and other items/select a custom scaling level/Custom sizing options screen loads..by default it should be 100%, if it is something greater like 200% it will display incorrectly.
The BridgeGate users passwords have a minimum eight chars long with upper and lower case letters, numbers. The user passwords are the same for portal, FTP, SSH, SFTP and all other related BridgeGate services the user has permissions to access. Note: This can be replaced with using LDAP or other authentication systems.
The Portal/Operations/Transaction page uses Java Script. Under certain circumstances old Java Script files may exist which could affect the transaction search results. This occurs mostly using IE. Try deleting the existing IE Browser Java Script files via the following, restart the browser and perform your search again.
Internet Options/General Tab/Browsing History/select the Settings Button
In the Temporary Internet Files tab, select the View Files button.
In the window, select view details and sort by Type.
Scroll down to the Java Script File types and delete the Java Script Files.
If you use a Wild Card pattern in the File Name Mask field for File or FTP Get Data types, a transaction/workflow will be instantiated for every file meeting the wild card pattern. For example, if you use FTM*.txt in the File Name Mask and the following files exist (FTM01.txt, FTM02.txt, FTM03.txt), three transactions/workflows will be generated. This happens regardless of where the Get Data is located in the workflow.
When troubleshooting long-running schedules keep in mind that this is somewhat of a misnomer. What is should actually be called is “long-running txn started by a schedule”. The first troubleshooting step we want to take is to look in the portal at the schedule that is reportedly running long to see what WF’s it invokes. Then look under “Active Transactions” in the portal for each of those WF’s. Even if the WF is set to not log you should still be able to see it (with or without a long “Elapsed Time”) in the portal under “Active Transactions”. If it is logging you should be able to drill down on the txn to see when it was started and where it is in processing. If it isn’t logging, then you won’t be able to drill down, but you could go into the server log to see when it was last started if you need to confirm that this is the long-running txn.
I applied the latest Service Pack and now my BridgeGate server will not start. The server log is showing the following exceptions:
org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml]
[org.springframework.web.context.support.XmlWebApplicationContext] Exception thrown from ApplicationListener handling ContextClosedEvent java.lang.IllegalStateException: ApplicationEventMulticaster not initialized – call ‘refresh’ before multicasting events via the context: Root WebApplicationContext: startup date [Tue Dec 20 11:34:21 MST 2016]; root of context hierarchy
Solution: Something caused the Service Pack to not fully unzip. Delete the contents of the
\bridgegate\server\webapps\ROOT folder and the ROOT.war and manually unzip the service pack.
Start the BridgeGate server. This should resolve your issues.
The default protocol can be changed by adding the following like to the bg_service.conf service file located under /bridgegate/bin directory
wrapper.java.additional.40=-Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1
Backup MySql Database using MySqlAdmin or mysqldump (Instructions below)
This is the root to the data archive backup directory. When this archive schedule runs, it will take all data from the data_archive, older than the DATA_RETENTION_TIME as configured in your bridgegate.xml file, and zip it up and place it in the \bridgegate\data_history folder location.
It is not configurable but you can delete these if you want. That just means that you will be unable to get back to older data_archive files if you ever had to.
I was able to make the connection by installing the Java Cryptography Extensions (JCE) Unlimited Strength Jurisdiction Policy files.
These files are not included in the standard Java deployments to comply with US export rules. However, they can be downloaded from the Oracle site at the following URL:
The zip file downloaded will contain two .jar files (local_policy.jar and US_export_policy.jar). These files must be copied to the BridgeGate installations.
Workbench:
C:\bgworkbench\java\jre\lib\security
Server:
C:\bridgegate\java\jre\lib\security
(Replace C: with the install drive for the software)
There should be files with the same names already in those directories — just overwrite the files that are there. The server/workbench will have to be stopped to replace the files.
If you have any questions, feel free to call me at (904)739-0300 x221. I will be happy to guide you through the steps.
The answer is that there are several options, each with their own trade-offs. Let me explain the best options to you, and you can choose the best one for your environment.
I. Increase maxThreads
The server.xml is configured such that the HTTP connector on port 8080 has a setting maxThreads=”300″. However, the AJP 1.3 connector, which is the connector from httpd (mod_jk), is configured with the default thread count. Increasing this thread count will increase the number of transactions actually running in parallel at any given time, but it may cause additional memory to be used.
Note that the memory size reported in either Task Manager or BridgeGate is not necessarily indicative of the actual amount of memory being used at any given time. This is due to the generational memory management of the Java Virtual Machine. Basically, the JVM may be holding onto 3.6GB of memory, but may be using only a small fraction of that at any given time. The only way to really be sure how much memory is being used is by attaching a profiling application, such as jvisualvm, jstat, or any of a number of other profilers.
The bottom line is that this setting will increase concurrent processing, but may use additional memory to do so.
II. Increase backlog
The other option is increasing the size of the “backlog” setting on the AJP connector. This setting is analogous to the “acceptCount” setting on the HTTP connector (see http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html). When all threads are in use, the system will stil accept up to this count of connections, which will wait for free threads to process.
Increasing this setting would keep the connections from being refused, but each additional connection sitting in the queue will wait for processing. Depending on how long they wait, the time to process may be longer than your SLA will allow.
We saw lots of ephemeral sockets being created and destroyed, which overwhelmed Windows. We were able to get rid of these errors by increasing the number of sockets available and decreasing the time they are in a TIME_WAIT state. We did that by adding some keys to the registry:
Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, add the following keys:
– TcpTimedWaitDelay: 30 (Decimal)
– MaxUserPort: 8FFF (Hexadecimal)
This increases the number of available connections from 16K to 32K, and ensures that connections are only in a TIME_WAIT state for 30 seconds, rather than the default of 120 seconds.
However, looking at the netstat command, I see 11,000 connections in the ESTABLISHED state connecting to DllHost. Since you run all the connections sequentially, you probably also want to lower the size of your MSMQ connection pool. In your bridgegate.xml, you should have the following entry:
<MSMQ_POOL MIN_SIZE=”2″ MAX_SIZE=”4″ />
You may need to experiment with the min and max values for maximum throughput. The defaults are 5 and 20, but there are many sockets opened per connection.
In BridgeGate Version 7 and 8, you can alter the file server/conf/web.xml:
<!-- ==================== Default Session Configuration ================= --> <!-- You can set the default session timeout (in minutes) for all newly --> <!-- created sessions by modifying the value below. --> <session-config> <session-timeout>30</session-timeout> </session-config>
The same setting exists in 6.0, but the file is jboss/server/bridgegate/system/jbossweb-tomcat55.sar/conf/web.xml
We support transactional MSMQ, just not *external* transactions.
There are two types of transactions with MSMQ. There is a specific MSMQ transaction service, which we support. Commit/Rollback is executed through a workflow Action item. Microsoft also has a method of integrating with external transactions, which can tie the MSMQ transaction in with another transaction (such as SQL Server). This uses something called DTC (Distributed Transaction Controller, I believe), and this is what we do not currently support.
Given that the MSMQ access through our product is done through our project, I’m not sure how it would be triggering a DTC transaction, so this requires some additional investigation into the error.
Getting the following exception when tried to upload a file.
[2015-05-27 10:36:17,640] INFO com.oidev.ftp.server.BGFileReceipt – Exception connection to BG Server Could not obtain connection to any of these urls: fe80:0:0:0:241a:9771:5f8:7c08%15:1099 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out]
[2015-05-27 10:36:17,701] INFO com.oidev.ftp.server.BGPluginLogin – start of upload detected
[2015-05-27 10:36:17,701] INFO com.oidev.ftp.server.ServerSession – !Wed May 27 10:36:17 EDT 2015! [41:ftps411387:96.243.230.33] WROTE: *150 Opening BINARY mode data connection. Ready to write file upload test – Copy (20).csv. (“/ftps411387/upload test – Copy (20).csv”) S T O R*
[2015-05-27 10:36:17,984] INFO com.oidev.ftp.server.ServerSession – !Wed May 27 10:36:17 EDT 2015! [41:ftps411387:96.243.230.33] WROTE: *226-Upload File Size:82940 bytes @ 80K/sec.*
[2015-05-27 10:36:17,985] INFO com.oidev.ftp.server.ServerSession – !Wed May 27 10:36:17 EDT 2015! [41:ftps411387:96.243.230.33] WROTE: *226 Transfer complete. CRC32=A1A3D86E (“/ftps411387/upload test – Copy (20).csv”) STOR*
[2015-05-27 10:36:17,990] INFO com.oidev.ftp.server.BGPluginLogin – end of upload detected
[2015-05-27 10:36:17,990] INFO com.oidev.ftp.server.BGFileReceipt – RealTimeMonitor called for file = /ftps411387/upload test – Copy (20).csv user = ftps411387
[2015-05-27 10:36:18,000] DEBUG org.jnp.interfaces.NamingContext – Failed to connect to fe80:1099
javax.naming.CommunicationException: Failed to connect to server fe80:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server fe80:1099 [Root exception is java.net.UnknownHostException: fe80]]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.oidev.bridgegate.SystemManager.getBridgeGateWorkFlow(SystemManager.java:196)
at com.oidev.ftp.server.BGFileReceipt.endUpload(BGFileReceipt.java:46)
at com.oidev.ftp.server.BGPluginLogin.endUpload(BGPluginLogin.java:200)
at com.oidev.ftp.server.STOR_handler.run(STOR_handler.java:847)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server fe80:1099 [Root exception is java.net.UnknownHostException: fe80]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
… 9 more
Caused by: java.net.UnknownHostException: fe80
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getByName(Unknown Source)
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:76)
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)
… 9 more
[2015-05-27 10:36:18,112] INFO com.oidev.ftp.server.ServerSession – !Wed May 27 10:36:18 EDT 2015! [41:ftps411387:96.243.230.33] READ : *PASV *
[2015-05-27 10:36:18,112] INFO com.oidev.ftp.server.BGPluginLogin – doCommand
[2015-05-27 10:36:18,112] INFO com.oidev.ftp.server.BGPluginLogin – PASV
[2015-05-27 10:36:18,112] INFO com.oidev.ftp.server.BGPluginLogin –
[2015-05-27 10:36:18,615] INFO com.oidev.ftp.server.ServerSession – !Wed May 27 10:36:18 EDT 2015! [41:ftps411387:96.243.230.33] WROTE: *227 Entering Passive Mode (10,67,59,14,12,38)*
[2015-05-27 10:36:18,719] INFO com.oidev.ftp.server.ServerSession – !Wed May 27 10:36:18 EDT 2015! [41:ftps411387:96.243.230.33] READ : *STOR upload test – Copy (21).csv*
[2015-05-27 10:36:18,719] INFO com.oidev.ftp.server.BGPluginLogin – doCommand
[2015-05-27 10:36:18,719] INFO com.oidev.ftp.server.BGPluginLogin – STOR
[2015-05-27 10:36:18,719] INFO com.oidev.ftp.server.BGPluginLogin – upload test – Copy (21).csv
[2015-05-27 10:36:23,001] INFO com.oidev.ftp.server.BGFileReceipt – Exception connection to BG Server Could not obtain connection to any of these urls: fe80:0:0:0:241a:9771:5f8:7c08%15:1099 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out]
[2015-05-27 10:36:23,031] INFO com.oidev.ftp.server.BGPluginLogin – start of upload detected
[2015-05-27 10:36:23,031] INFO com.oidev.ftp.server.ServerSession – !Wed May 27 10:36:23 EDT 2015! [41:ftps411387:96.243.230.33] WROTE: *150 Opening BINARY mode data connection. Ready to write file upload test – Copy (21).csv. (“/ftps411387/upload test – Copy (21).csv”) S T O R*
[2015-05-27 10:36:23,366] INFO com.oidev.ftp.server.ServerSession – !Wed May 27 10:36:23 EDT 2015! [41:ftps411387:96.243.230.33] WROTE: *226-Upload File Size:82940 bytes @ 80K/sec.*
— Answer –
It looks like it is be trying to use IPv6 addresses. If you can, disable IPv6 on that system. If you cannot, you will need to update the BridgeGate services to prefer IPv4. To do that, add the following option to the bg_*.conf files (pick an unused number where it says “XX”):
wrapper.java.additional.XX=-Djava.net.preferIPv4Stack=true
Modify the urlrewrite.xml located at \bridgegate\conf to have the rule. Note make sure ampersands (“&”) properly encoded, as follows:
<rule> <from>/report-856$</from> <to type="forward">/portal/executeworkflow?accountName=hsn&wfGroupName=adhoc&wfName=856trans_from_today</to> </rule>
Add the following to the bg_service.conf located in the \bridgegate\conf directory and restart the server. Prepare yourself for lots of logging.
-Djavax.net.debug=all
Stage the Service Pack file to: /bridgegate/servicepack
(Note: Change ownership of file if BG not running as root)
> chown bgate:bgate /bridgegate/servicepack/bridgegateSP_10.0.XXXXXX.zip
Execute the following commands as root:
> ls /bridgegate/servicepack > service bridgegate stop > rm /bridgegate/server/webapps/ROOT.war > rm -r /bridgegate/server/webapps/ROOT/ > rm /bridgegate/server/webapps/update.war > rm -r /bridgegate/server/webapps/update/ > unzip -o /bridgegate/servicepack/bridgegateSP_10.0.XXXXXX.zip -d / > chown -R bgate:bgate /bridgegate/server/* > service bridgegate start
Add the following in the bg_service.conf file:
# Log Level for log file output. (See docs for log levels)
wrapper.logfile.loglevel=DEBUG
wrapper.debug=true
This should output tons of info to the BridgeGateWrapper.log file. Don’t leave it like this for long.
In BridgeGate just create a SendData with the email adapter and use the following table for the cell carrier.
http://www.emailtextmessages.com/
US & Canadian Carriers |
|
|
|
3 River Wireless |
|
|
ACS Wireless |
|
|
Alltel |
|
|
AT&T |
|
|
Bell Canada |
|
|
Bell Canada |
|
|
Bell Mobility (Canada) |
|
|
Bell Mobility |
|
|
Blue Sky Frog |
|
|
Bluegrass Cellular |
|
|
Boost Mobile |
|
|
BPL Mobile |
|
|
Carolina West Wireless |
|
|
Cellular One |
|
|
Cellular South |
|
|
Centennial Wireless |
|
|
CenturyTel |
|
|
Cingular (Now AT&T) |
|
|
Clearnet |
|
|
Comcast |
|
|
Corr Wireless Communications |
|
|
Dobson |
|
|
Edge Wireless |
|
|
Fido |
|
|
Golden Telecom |
|
|
Helio |
|
|
Houston Cellular |
|
|
Idea Cellular |
|
|
Illinois Valley Cellular |
|
|
Inland Cellular Telephone |
|
|
MCI |
|
|
Metrocall |
|
|
Metrocall 2-way |
|
|
Metro PCS |
|
|
Microcell |
|
|
Midwest Wireless |
|
|
Mobilcomm |
|
|
MTS |
|
|
Nextel |
|
|
OnlineBeep |
|
|
PCS One |
|
|
President’s Choice |
|
|
Public Service Cellular |
|
|
Qwest |
|
|
Rogers AT&T Wireless |
|
|
Rogers Canada |
|
|
Satellink |
|
|
Southwestern Bell |
|
|
Sprint |
|
|
Sumcom |
|
|
Surewest Communicaitons |
|
|
T-Mobile |
|
|
Telus |
|
|
Tracfone |
|
|
Triton |
|
|
Unicel |
|
|
US Cellular |
|
|
Solo Mobile |
|
|
Sprint |
|
|
Sumcom |
|
|
Surewest Communicaitons |
|
|
T-Mobile |
|
|
Telus |
|
|
Triton |
|
|
Unicel |
|
|
US Cellular |
|
|
US West |
|
|
Verizon |
|
|
Virgin Mobile |
|
|
Virgin Mobile Canada |
|
|
West Central Wireless |
|
|
Western Wireless |
1) Create a dummy directory under the bridgegate\FTPServer directory.
I created mine as bridgegate\FTPServer\FauxRoot_DoNotDelete.
2) Config bridgegate.xml to use this directory as the FTP root.
<FTP_SSH_CONFIG SERVER_PORT=”22″ SSH2_DSA_HOST_KEY=”” SSH2_DSA_HOST_KEY_PASSWORD=”” SSH2_RSA_HOST_KEY=”” SSH2_RSA_HOST_KEY_PASSWORD=”” VFS_ROOT=”C:\bridgegate\ftpserver\FauxRoot_DoNotDelete”/>
Below is a way to fix an out of sync instance of MySQL Master-Master Replication.
This way does not require restarting the MySQL services on either instance and requires no file deleting.
The steps will also work with a MySQL Master-Slave replication setup.
The key change is the –master-data attribute in the mysqldump command from the master database.
https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html#option_mysqldump_master-data
“Use this option to dump a master replication server to produce a dump file that can be used to set up another server as a slave of the master. It causes the dump output to include a CHANGE MASTER TO statement that indicates the binary log coordinates (file name and position) of the dumped server. These are the master server coordinates from which the slave should start replicating after you load the dump file into the slave.”
________________________________________
——————-
MySQL Master-Master Replication is broken.
Note: Replace the following values.
Good Server IP: 192.168.10.11
Bad Server IP: 192.168.10.22
Good Server NAME: GOODHOST
Bad Server NAME: BADHOST
MySQL UserName: MySQLUSERNAME
MySQL Password: MySQLPASWORD
Note: All of these commands can be run from the ‘Good Server’, if you open two separate Command Prompts.
Note: If you run the ‘show slave status\G’ command too soon, you may not get the expected result. Re-run the command again to verify.
Note: Most of the time will be spent during importing the mysqldump in step 3.
——————-
1. On Both Servers
STOP BridgeGate service on both systems.
Disable BridgeGate service to prevent auto-restarting.
2. On the Good Server
Open a Command Prompt.
Note: If extra databases are being replicated, add them to the list: “–databases bridgegate bd1 bd2 bd3”
Note: Do not include the following databases: mysql information_schema, and performance_schema
————
e:
cd bridgegate\mysql\bin
mysql -h 192.168.10.11 -u MySQLUSERNAME -p
MySQLPASWORD
show databases;
exit;
mysqldump -h 192.168.10.11 -u MySQLUSERNAME -p –add-drop-table –quick –master-data –databases bridgegate > e:\bridgegate\bg.all.sql
MySQLPASWORD
————
3. On the Rebuilding Server
Note: Open a Command Prompt.
Note: Expected output of ‘slave status’ is “Slave_IO_State: Waiting for master to send event”
————
e:
cd bridgegate\mysql\bin
mysql -h 192.168.10.22 -u MySQLUSERNAME -p
MySQLPASWORD
stop slave;
exit;
mysql -h 192.168.10.22 -u MySQLUSERNAME -p bridgegate < e:\bridgegate\bg.all.sql
MySQLPASWORD
mysql -h 192.168.10.22 -u MySQLUSERNAME -p
MySQLPASWORD
start slave;
show slave status\G
flush tables with read lock;
show master status;
————
4. On the Good Server
Note: Set the slave here to be in synch with Rebuilding Server. Use the file name and log position from the previous step.
Note: Expected output of ‘slave status’ is “Slave_IO_State: Waiting for master to send event”
————
mysql -h 192.168.10.11 -u MySQLUSERNAME -p
MySQLPASWORD
stop slave;
change master to master_log_file=’BADHOST-bin.??????????’, master_log_pos=???????????;
start slave;
show slave status\G
————
5. On Both Servers
Enable BridgeGate service.
Start BridgeGate service on both systems.
Execute transactions on either server to test replication of database.
Also, test for Active=True/False and Loadbalancing settings at this time.
Note: Expected output of ‘slave status’ is “Slave_IO_State: Waiting for master to send event”
After both servers are up and running, check the ‘slave status’ of both MySQL servers.
————
show slave status\G
————
I was thinking it would be cool to use BridgeGate as a reporting tool. To do that I would need to have the workflow executed on Demand with a URL which I know can be done?
The other think I didn’t know is if a variable could be entered as part of the url or could be promoted.
I.E. A report that would be configured to run by different catalog code and the user would provide the code.
— Answer —
The easiest way would be setting up a WF with the BridgeGateHTTP Adapter with ‘Enable Workflow to be Executed as a Service’.
Create New In-Values with the ‘Add to Workflow Session’ selected to receive the values you want to receive into the Workflow.
The URL Preview will add the new URL parameter for use.
http://[SERVER_URL]/portal/executeworkflow?accountName=samples&wfGroupName=sample1&wfName=test_wf&catalog_code=[SESSION_VALUE]
http://localhost:8080/portal/executeworkflow?accountName=samples&wfGroupName=sample1&wfName=test_wf&catalog_code=123456
You can’t use a PPK file from BridgeGate. The PPK is a PuTTY-(and related tools)-specific type of key. BridgeGate uses OpenSSH keys. You can export a .ppk file as an OpenSSH key from PuttyGen using the Conversions/Export OpenSSH Key menu option.
*******************************************
Importing a P12 (i.e.: PKCS12) Certificate Chain into a BridgeGate Java KeyStore (JKS)
*******************************************
Keytool path: C:\bridgegate\java\bin\keytool.exe
Openssl path: C:\bridgegate\utils\openssl\openssl.exe
P12 Certificate Chain: C:\data\cert\Bridgegate_HUBCertificates.p12 (Replace BridgeGate_HUBCertificates with your file)
BG Staging JSK KeyStore: C:\data\cert\bridgegate.jks
*** Note: The Alias used in the JKS does not need to match the Common Name (CN) of the Client System Key. The more important thing is that the BridgeGate Java KeyStore (JKS) does not contain duplicate aliases. ***
1) List and verify P12 Certificate Chain contents:
c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\data\cert\Bridgegate_HUBCertificates.p12
Enter keystore password:
***************** WARNING WARNING WARNING *****************
* The integrity of the information stored in your keystore *
* has NOT been verified! In order to verify its integrity, *
* you must provide your keystore password. *
***************** WARNING WARNING WARNING *****************
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
Alias name: Bridgegate_HUB
Creation date: Jul 11, 2014
Entry type: SecretKeyEntry
2) IF the P12 Certificate Chain file is not password locked, you will need to recreate is with a password:
*** Export you current certificate to a password less pem type. Note: Leave the ‘Import Password’ field empty in this step.
c:\bridgegate\utils\openssl>openssl pkcs12 -in C:\data\cert\Bridgegate_HUBCertificates.p12 -out C:\data\cert\export.tmp.pem -nodes
Enter Import Password:
MAC verified OK
*** Convert the password less pem to a new pfx file with password:
c:\bridgegate\utils\openssl>openssl pkcs12 -export -in C:\data\cert\export.tmp.pem -out C:\data\cert\Bridgegate_HUBCertificates.locked.p12 -name “Bridgegate_HUB”
Loading ‘screen’ into random state – done
Enter Export Password:
Verifying – Enter Export Password:
3) Confirm Alias name is new password locked P12 Certificate Chain. Step 2 creates alias based on -name argument, if this is left out, the alias name can be “1”.
*** Confirm Chain length of 3 and the Owner/Issuer of each Certificate are in the proper order. ****
c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\data\cert\Bridgegate_HUBCertificates.locked.p12
Enter keystore password: ******
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
Alias name: bridgegate_hub
Creation date: Jul 14, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=Bridgegate_HUB ClientSystem, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
.
.
.
Certificate[2]:
Owner: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
.
.
.
Certificate[3]:
Owner: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
4) Import the P12 Certificate Chain into your BridgeGate Java KeyStore (JKS).
**** Note: You can alter the Alias name with the -alias and -destalias arguments. ****
c:\bridgegate\java\bin>keytool -importkeystore -destkeystore C:\data\cert\bridgegate.jks -srckeystore C:\data\cert\Bridgegate_HUBCertificates.locked.p12-srcstoretype PKCS12
Enter destination keystore password:
Enter source keystore password:
Entry for alias Bridgegate_HUB successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled
5) Verify the JKS contains the new Certificate under the correct Alias.
*** WARNING: This password field is displayed on screen as clear text! ***
c:\bridgegate\java\bin>keytool -v -list -storetype jks -keystore C:\data\cert\bridgegate.jks > c:\data\cert\out.txt
Enter keystore password: *********
*******************************************
Importing a PEM formatted Certificate Chain into a BridgeGate Java KeyStore (JKS)
*******************************************
Keytool path: C:\bridgegate\java\bin\keytool.exe
Openssl path: C:\bridgegate\utils\openssl\openssl.exe
Cert working location: C:\cert\
PEM Files:
Root CA Certificate: RootCACertificate.pem
Modality (intermediate) CA Certificate: prodCertificate
Client System Certificate: Bridgegate_HUB.pem (Replace Bridgegate_HUB with your pem file)
Client System Key: Bridgegate_HUB.key (Replace Bridgegate_HUB with your key file)
*** Note: The Alias used in the JKS does not need to match the Common Name (CN) of the Client System Key. The more important thing is that the BridgeGate Java KeyStore (JKS) does not contain duplicate aliases. ***
1) Obtain the following PEM files.
– Root CA Certificate
– Modality (intermediate) CA Certificate
– Client System Certificate
– Client System Key (PK)
2) Get the Common Name (CN) for the Client System Key.
c:\bridgegate\utils\openssl>openssl x509 -in c:\cert\Bridgegate_HUB.pem -signkey C:\cert\Bridgegate_HUB.key -noout -issuer
Loading ‘screen’ into random state – done
Getting Private key
issuer= /C=US/ST=TN/L=Nashville/O=ICA/OU=IT/CN=Bridgegate_HUB ClientSystem
3) Create a P12 Certificate Chain file.
Each of the Certificate files is a text file. Create a blank file named chain.tmp and copy-and-paste the following order: ‘Root CA Cert’, ‘Modality (intermediate) CA Certificate’ and ‘Client System Cert’ into one file. Replace the CN from step 2 in the -name argument below. Be sure to create a password at the ‘Export Password’ prompt. A password is required for the keytool in a following step.
c:\bridgegate\utils\openssl>openssl pkcs12 -export -in C:\cert\chain.tmp -inkey C:\cert\Bridgegate_HUB.key -out C:\cert\Bridgegate_HUBCertificates.chain.p12 -name “Bridgegate_HUB”
Loading ‘screen’ into random state – done
Enter Export Password: ***********
Verifying – Enter Export Password: ***********
4) Verify the contents of the new P12 Certificate Chain file. Step 3 creates alias based on -name argument, if this is left out, the alias name will be something like”1″.
*** Confirm Chain length of 3 and the Owner/Issuer of each Certificate are in the propper order. ****
c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\cert\Bridgegate_HUBCertificates.chain.p12
Enter keystore password: ***********
.
.
.
.
Alias name: Bridgegate_HUB
Creation date: Jul 11, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=Bridgegate_HUB ClientSystem, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
.
.
.
.
Certificate[2]:
Owner: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
.
.
.
.
Certificate[3]:
Owner: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US
.
.
.
.
5) Import the P12 Certificate Chain into your BridgeGate Java KeyStore (JKS).
**** Note: You can alter the Alias name with the -alias and -destalias arguments. ****
c:\bridgegate\java\bin>keytool -importkeystore -destkeystore C:\cert\bridgegate.jks-srckeystore C:\cert\Bridgegate_HUBCertificates.chain.p12 -srcstoretype PKCS12
Enter destination keystore password:
Enter source keystore password:
Entry for alias Bridgegate_HUB successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled
6) Verify the JKS contains the new Certificate under the correct Alias.
*** WARNING: This password field is displayed on screen as clear text! ***
c:\bridgegate\java\bin>keytool -v -list -storetype jks -keystore C:\cert\bridgegate.jks> c:\cert\out.txt
Enter keystore password: *********
To enable TLSv1.2 to be used as the default, add the following to the bg_service.conf:
wrapper.java.additional.40=-Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1
When backing up databases manually you should use the —hex-blob option to ensure encrypted data is not corrupted. We have seen issues in the past where an ascii dump has issues.
I found this program to be useful in finding what directories are taking up the most space on a drive.
“WinDirStat is a disk usage statistics viewer and cleanup tool for various versions of Microsoft Windows.”
Or download installer from Ninite: https://ninite.com/
The command prompt client is probably executing different commands than what BridgeGate is executing (the low-level FTP protocol commands, like CWD, PASV, RETR, and the like). The library also has to do additional parsing of the data received from the server.
(Side note: You could run wireshark or some other network sniffing tool to see exactly what is getting sent and what we are sending, but it is likely that we are simply executing different commands in a different order than the Windows client.)
We use a third-party library (Apache Commons Net) to control the FTP connection. This library creates the socket connections and directly implements the FTP protocol (RFC 959).
SFTP server is not accepting connections.
Status: Connecting to myserver… Response: fzSftp started, protocol_version=6 Command: open “user@myserver” 22 Command: Trust new Hostkey: Once Command: Pass: ********* Error: Authentication failed. Error: Critical error: Could not connect to server
Should there be any keys in the bridgegate.xml?
<FTP_SSH_CONFIG SERVER_PORT=”22″ SSH2_DSA_HOST_KEY=”” SSH2_DSA_HOST_KEY_PASSWORD=”” SSH2_RSA_HOST_KEY=”” SSH2_RSA_HOST_KEY_PASSWORD=”” VFS_ROOT=”C:\\bridgegate\FTPServer\accounts\root”/>
Or is this where I have to setup the keys in the workbench? When we setup the 8.0 versions we used self signed certs, this time I’m using the .JKS previously created.
— Answer —
The SSH key elements are unrelated to the .JKS keystore. If values are not included in those elements, keys are generated at startup. Those keys are also not used for authentication. The system should be connecting to BridgeGate (through Hazelcast) for authenticating SSH.
Our BridgeGate server will not start. The first exception in the stack trace is this:
Caused by: java.net.BindException: Address already in use: JVM_Bind
Which indicates that something is already using one of the ports you are trying to open. Specifically (the next element up the chain):
Caused by: java.net.BindException: Address already in use: JVM_Bind <null>:80
So, port 80 is in use by something that is not BridgeGate. Now, trying to find what is running on port 80:
netstat -ano | find “:80”
yields:
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
You may have IIS or another webserver running on this server. We recommend installing Bridgegate Webserver on port 8080
There is no application requirement that requires you keep the same version on your Client and your Server. However, as a Best Practices, you should update your Client as your BG
You can execute a workflow from the BridgeGate Workbench or by using an URL. You can run any Workflow from the command line by executing the following command in a DOS Window or by using a programming language.
To Execute the Workflow on the computer (local host) where the BridgeGate Workbench is installed, Execute the Workflow by using the following command:
/bridgegate/utils/curl http://localhost:8080/portal/translate?accountName=samples&wfGroupName=sample1&wfName=PurchaseOrders&userName=sample&password=mypassword&KEY=VALUE
The optional [KEY=VALUE] will be added to the Workflow Session as SESSION_DATA. The KEY can be any alpha numeric text that is not one of the above reserved keys.
BridgeGate™ can be used as an EAI application. Additionally, BridgeGate™ goes beyond current EAI systems and is considered a (Transformation and Exchange Infrastructure) that allows connectivity and integration of single data sources, multiple data sources, external systems and separate partner networks.
BridgeGate™ is written in Java and is able to run on any platform that supports the Java Virtual Machine. BridgeGate Server clusters very well with heterogeneous networks consisting of Windows and Unix/Linux/Solaris machines.
Check out our installation guide for more details.
BridgeGate™ has unofficially been on the market since January 2002 but was officially released on July 1, 2002. The technology is both new and patented; although the underlying technology (Java and XML) has been around for some time.
Yes. One of the biggest strengths of BridgeGate™ is that it does not force you to use any particular data format or transmission protocol; it is completely open.
Absolutely! BridgeGate™ can be set up to send data (and different data formats) to multiple external entities all from the same input source. It is merely a matter of setting up where you’d like the data to go and how it should be formatted. There’s no limit to the number of output destinations.