Transaction Import Adaptor

• Transaction Import Adaptor
  • When would I use it?
  • What does it do?
  • How does it work?
  • How would I use it?

The Transaction Import Adaptor is known as '800xA Integration'; however, the adaptor can be used with other systems.

When would I use it?

The adaptor is used to import transactions that belong to a transaction editor (not despatch transactions) from an external system into MineMarket. The source or destination stockpiles can be normal or 3D stockpiles.

As well as the usual quantity and quality attributes, this adaptor can specify:

• Where in a stockpile (X, Y, Z coordinates) material is coming from or going to
• What sort of reclaiming process is used at the source stockpile (Loader, Boom or Bridge reclamation)
• What sort of stacking process is used at the destination stockpile (Cone, Step, Chevron, Windrow or Loader stacking)

You must be comfortable with extensible markup language (XML), XML schema definitions (XSDs) and configuring IMS Integration Hub publish/subscribe adaptors.

What does it do?

The Transaction Import Adaptor is an IMS Integration Hub publish/subscribe adaptor. It is passed XML messages from IMS Integration Hub containing sets of transactions from an external system. The adaptor processes these sets of transactions and then uses a .NET Remoting call to invoke the MineMarket Service as a client. The calls to MineMarket use transaction editors (identified in the XML message) to create the objects associated with the transactions from the XML transaction set message in MineMarket.

How does it work?

An IMS Integration Hub publish/subscribe adaptor (the Transaction Import Adaptor) is set up to read from an OUTBOUND table in the IMS Integration Hub database in the usual way that IMS Integration Hub database publish/subscribe adaptors operate.

An XSD file (TransactionSet.xsd) is registered in IMS Integration Hub with the adaptor. This XSD file specifies the format of the transaction messages that the adaptor can process. This file is used by IMS Integration Hub to validate the messages it reads from the OUTBOUND table in its database before sending them to the Transaction Import Adaptor for processing.

The Transaction Import Adaptor is configured to connect to the MineMarket Service using the same .NET Remoting URL that MineMarket Client applications use. It uses this .NET Remoting connection to create transaction (and related) objects in MineMarket.

The external system also uses the TransactionSet.xsd file as a guide on how to format the messages that it writes to the IMS Integration Hub OUTBOUND table.

Processing is triggered by the external system writing to the OUTBOUND table in the IMS Integration Hub database.

How would I use it?

IMS Integration Hub needs to be set up to use the Transaction Import Adaptor DLL as a publish/subscribe adaptor in the usual way:

• The adaptor needs to be registered with IMS Integration Hub to process messages.
• The adaptor has a configuration setting that must specify the URL on which to contact the MineMarket Service. This must be the same value that MineMarket clients use to contact the MineMarket Service.
• An OUTBOUND table must be set up in the IMS Integration Hub database to receive the XML transaction messages from the external system.
• The TransactionSet.xsd file must be registered with IMS Integration Hub as the validator for the XML messages read by the Transaction Import Adaptor.

MineMarket needs some configuration to support some expectations that the adaptor has:

• The XML messages used to contain the transactions sent from the external system to the adaptor refer to certain objects that must already exist in MineMarket configuration. These objects are used in processing instances of the XML messages, but are not directly related to the message content. Examples are the transaction editors required to process the messages, units of measure and analyte definitions.
• The MineMarket message processing objects referred to above are referenced by their Alias1 values. These Alias1 values must be set so that the message processing can be routed to the correct instances. For example, there may be different kinds of transactions that need to be routed to different transaction editors.
• The Alias1 values of the objects required for message processing must be communicated to the team responsible for sending the transaction messages from the external system. It would be advisable to follow standardised naming conventions for the Alias1 values to make this easier.
• The XSD file that controls the message format of the transaction messages must also be communicated to the team responsible for sending the transaction messages from the external system, so that they know how to format their XML messages.