Invalid Binary Header on Replication
This is a Technical (IT) Helpdesk topic
See the Discussion tab for problem solving discussion.
Contents
Problem Overview
The Aquila Replication software (aqrepl.exe) is unable to connect to the WinCGI app server module located at https://nww.mdsas.nhs.uk/ibid/cgi-bin/aquilaweb.exe/bin.
The error message returned is "Invalid binary header. Either incompatible or not a binary message". This error is generated from the client-side channel component in aqrepl.exe when it does not received the correct format of reply from the app server. It is always followed by the first 500 characters of the actual reply received.
In this case the full error message is:
Error copying replication data to http://10.195.1.71/ibid/cgi-bin/aquilaweb.exe/bin Invalid binary header. Either incompatible or not a binary message. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> .<html xmlns="http://www.w3.org/1999/xhtml"> .<head> .<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> .<title>500 - Internal server error.</title> .<style type="text/css"> .body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} .fieldset{padding:0 15px 10px 15px;} .h1{font-size:2.4em;margin:0;color:#FFF;} .h2{f
(Notice the actual response received is an HTML document entitled 500 - Internal Server Error)
Replicating the Problem
In order to view the problem, one must run aqrepl.exe. It is a console app and should be run through a console window, where if necessary output can be piped to a text file.
The command line is:
aqrepl SOURCE_URI DESTINATION_URI <params>
for example:
aqrepl http://www.bibid.org.uk/cgi-bin/aquilaweb.exe/bin https://nww.mdsas.com/ibid/cgi-bin/aquilaweb.exe/bin /B1 /R1 /V
where:
- /B1 = batch size of 1 record. This will copy only one audit trail record from the source database to the target database
- /R1 = repeat 1 time. So batch size * repeat count = total number of audit trail records to copy in a single run
- /V = verbose output. Outputs progress record counts and a whole host of debug information.
The aqrepl.exe module is part of the client installation. It can also be download separately from http://evolutionhealthcaresystems.co.uk/downloads/cat_view/13-misc-downloads
The output from the arepl application should be as follows:
AQREPL:: Aquila Replication Module v1.1.1 © Evolution Healthcare Systems Limited www.EvoHelpdesk.co.uk Batch size: 1, repeat count: 1 http://www.bibid.org.uk/cgi-bin/aquilaweb.exe/bin is the database URL RemoteDataAdapter: RemoteDataAdapter RemoteServiceName: AquilaService DataStreamerClass: TDABin2DataStreamer RemoteMessageClass: TROBinMessage RemoteMessageEnvelopeCount: 1 #EnvelopeMarker0: AES #EnvelopeType0: TROAESEncryptionEnvelope AES Password = t9ux9creSWUZAC56KuCRewU5hu4eSP36ru68JEt4Ed34geseyUbRACrAStUgAtre ChannelType: TROIndyHTTPChannel ChannelTargetURL: http://localhost:8099/bin Initialising CopyData procedure Before open remote data After open remote data After resetting remote fetching After confirming remote dataset record count Before inserting remote record ILOG_ID=1U9ZZv4Jun28D12D2DUYIkN UNIT_ID=ZZ12345678 DELTA_DETAILS=<?xml version="1.0" encoding="UTF-16"?><c ct="0" tn="IBID_MAIN" idf="IBID_MAIN_ID" idv="1U9ZZv3NHDC43F51D2CGc5Y">[..snip..]</c> TABLE_NAME=IBID_PSUASSESSMENT ID_FIELD=IBID_PSU_ID ID_VALUE=1U9ZZv3NHDC43F51D2CGc5Y CHANGE_TYPE=0 CHANGE_STATUS=1 LAST_UPDATE_TIME=05/10/2012 16:14:41 PRIVATE_DELTA_DETAILS= Before posting remote edits to ILOG_REPL After posting remote edits to ILOG_REPL After applying remote updates to ILOG_REPL Before making edits to ILOG_SOURCE Before posting edits to ILOG_SOURCE After posting edits, before applying updates to ILOG_SOURCE After applying updates to ILOG_SOURCE Replication to http://localhost:8099/bin succeeded at 12/10/2012 15:04:38. Due again at 12/10/2012 15:09:38 Replication completed successfully
After the initial preamble, there is a section of data starting with RemoteDataAdapter down to ChannelTargetURL that details the configuration of the client - server connection.
Analysis
Programming
This problem is symptomatic of using an incorrect URI to access the app server. We have seen it occur when the /bin path is omitted from the URI for instance. However the same app server component (AquilaWeb.exe) is in use in other locations (including http://ibid.mdsas.com/cgi-bin/aquilaweb.exe/bin) without this problem occurring. We have also added additional "debug" output to the aqrepl.exe module that confirms the URI to be correct. Moreover, the URI is actually provided by a command line parameter so when running the aqrepl.exe app manually one can provide any URI.
Server Configuration
Indications are that the problem is not programming related, due to the fact that the same app server module is in use successfully in other places. However, there is contradictory evidence in that it is entirely possible to run the AquilaCRS (IBID) desktop application to connect to the app server at nww.mdsas.com. Moreover, the same datatable that is being accessed by the aqrepl program (ILOG_REPL) can be successfully opened and manipulated by the AquilaCRS.exe client program. The significance of this is that the desktop app (aquilacrs.exe) and the replication module (aqrepl.exe) use identical methods of connection.
Solution
This problem was fixed in version 1.1.5 of Aquila. If you are running older versions of the software you should upgrade immediately. See Making sure the National Database URL is up to date for more details.
If you are running newer versions of the software, then this type of problem is most likely to occur if you have an incorrect URI for the National Datbase Server. See the Aquila Software Status page for the correct information.