Features of the Socket Gateway
The Socket Gateway has various features that enable you to create an interface between the socket and the ObjectServer.
Centralized property management
The gateway uses centralized property management and separates properties from data processing configuration. To configure the common gateway properties and the Socket Gateway properties, use the G_SOCKET.props properties file. To configure data processing, use the table replication definition file and the mapping file. To specify a set of commands that the gateway performs automatically each time it starts, use the startup command file.
The following topics describe the settings required within the properties file.
Setting the format of headers and trailers added to alerts
Whenever a delete, update, or insert occurs in the ObjectServer fields, the gateway sends header and trailer information with the changed alerts to the socket. Using the properties file, you can define the format in which the gateway adds the header and trailer in the alerts.
The following example shows header and trailer format definitions of the deletes, updates, and inserts:
# Gate.Socket.DeleteHeader : '\nStart of delete line\n'
# Gate.Socket.DeleteTrailer : '\nEnd of delete line\n'
# Gate.Socket.UpdateHeader : '\nStart of update line\n'
# Gate.Socket.UpdateTrailer : '\nEnd of update line\n'
# Gate.Socket.InsertHeader : '\nStart of insert line\n'
# Gate.Socket.InsertTrailer : '\nEnd of insert line\n'
Where, \n instructs the start
of the next line.
Passing table data
The gateway can replicate the data in any table between the ObjectServer and the destination socket. Details of the tables to be replicated are stored in the table replication definition file. Use the Gate.RdrWtr.TblReplicateDefFile property to specify the location of the table replication definition file.
Mapping table data
The gateway writes the alerts received from the various tables in the ObjectServer onto the socket in a format defined by the map definition file. To specify the map definition file, use the Gate.MapFile property.
Failover and Failback
Failover
functionality comes into operation when the gateway loses its connection
to the primary ObjectServer.
When the primary ObjectServer fails,
the reader connects to the backup ObjectServer as
configured using the Tivoli Netcool/OMNIbus Server
Editor (nco_xigen). To specify that the gateway fails
back to the primary ObjectServer,
set the Gate.RdrWtr.FailbackEnabled property
to TRUE.
When the reader has detected that it is now connected to a backup ObjectServer, it periodically polls for the return of the primary ObjectServer at the frequency specified by the Gate.RdrWtr.FailbackTimeout property. When the primary ObjectServer is detected again, the reader automatically fails back to the primary ObjectServer.
Process Agent control
You can control how the gateway runs by using Process Agent (PA) control.
The gateway can be run under PA control. The Gate.PAAware property indicates whether the gateway is PA aware. The Gate.PAAwareName property indicates which PA is running the gateway.
Error handling
You can troubleshoot problems with the gateway by consulting error messages. To help you do this, the gateway has configurable error handling.
Error handling is provided by the Netcool/OMNIbus Gateway Toolkit (NGTK) library. To specify that the NGTK library logs debug messages, set the Gate.NGtkDebug property to TRUE.