A Java package has been supplied that will handle the task of communicating with Fusion Connect. This section will explain how to use these classes in conjunction with your own adapter logic to perform the complete functionality of a device adapter.
Once the adapter has been completed such that it is capable of communicating with devices, processing their messages and communicating with Fusion Connect, it must be hosted at a URL to which Fusion Connect can make its web services requests. Once this is done, you must provide this URL to and the gateway can be registered. If you are registering the gateway yourself, this can be done from the Data Gateway's tab of the Connect menu. When Fusion Connect registers a new gateway, it will send a bind request to the web services host URL provided. This will include the gateway code designated by the user to uniquely identify the gateway to Fusion Connect, the hostname and port to which the adapter must send messages from that gateway, and a key, which it will send in all future web services requests to that gateway for the purposes of authentication. Note that if the key provided in the later request does not match the one sent by the original bind request, the adapter must ignore the request. If you choose not to use the Java classes provided to handle communication with the Fusion Connect application server, then you must store these connection details somehow.
Again, there are no requirements for how your adapter receives or processes messages. The classes MessageFeed and MessageFeedRs are examples of how the adapter might receive messages sent via a SOAP or REST PUT request, respectively. In these examples, the source of the messages would supply the gateway code and would already have marshaled the message or batch of messages into the proper XML string format, and the adapter automatically forwards these messages to Fusion Connect.
In order to send a device message to Fusion Connect, an adapter must first translate that message into a format that is immediately ready for the Fusion Connect platform to interpret. The format that Fusion Connect accepts is an XML string; the marshall() and marshallBatch() methods of the AdapterMessageXMLFactory class in the provided Java packet will generate strings of this format from MessageXtype or JAXBElement objects. So, you need only process the raw device message into one of these two formats. If you wish to implement other methods to generate messages of the accepted format, you can do so by marshalling an object according to the schema located at "http://www.seecontrol.com/nexus/XMLSchema schema/generic-messages.xsd", as is done in AdapterMessageXMLFactory. Next, the adapter must call AdapterClient.process(), which will take care of the rest; it calls AdapterClient.send(), which will fetch the synchronized map of gateway codes to AdapterConnects from the AdapterConfig instance, from which it will get the AdapterConnect of the gateway corresponding to the device that sent the message. AdapterClient will then use the connection information from this AdapterConnect to open a TCP socket with Fusion Connect and send the XML string of the message.
Receiving Directives One of the three web services methods provided in the AdapterBindingRs class is the directive method. Through this request, Fusion Connect can send a single message or a batch of messages to the adapter, along with the code of the gateway the messages are meant for. However, beyond checking the validity of the gateway code and key, and checking that none of these parameters are empty, the body of this request is left blank. You must complete the body of this method with whatever logic is necessary to handle a directive, or point it towards a method that will handle the directive. The "messages" string will be of the same XML format that messages sent via TCP are required to be in, so you must decode this message or batch of messages, and, when necessary, craft messages using the communication protocol of the destination device and send them.
De-Registering a Gateway When a gateway is no longer needed, it will be manually deleted by Fusion Connect staff. When this occurs, Fusion Connect will send an unbind request to the web services host URL it has stored. This request, if verified with the correct key, will inform the user that the gateway has been deregistered and that Fusion Connect will no longer accept messages from it. If you choose not to use the Java classes provided to handle communication with Fusion Connect, then the adapter must somehow handle the fact that the gateway is no longer registered, either by forgetting the connection details associated with the bound gateway or by somehow marking it as invalid.