Invalid Binary Header on Replication

From EHS Help
Jump to: navigation, search

This is a Technical (IT) Helpdesk topic

See the Discussion tab for problem solving discussion.

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.

Retrieved from ‘https://evolutionhealthcaresystems.co.uk/help/index.php?title=Invalid_Binary_Header_on_Replication&oldid=1284’