The adapter passes data between Oracle Utilities Network Management System and the MDS, transforming the data based on the configuration files and tables. Messages sent and received using MQSeries are formatted in XML. The types of messaging that are supported include the following:

There are a number of mobile data systems produced by various vendors. These systems allow the end customer to specify the contents of orders that are sent to the crews and the various ways that the crews can report on their progress of their work in the field. In addition, crews can request information from the dispatcher and from other systems in the customer's organization. The number of options and capabilities vary between the mobile data system vendors.

Oracle Utilities Network Management System allows the end customer a large number of options in the kinds of data that are associated with different kinds of objects, including customers, customer calls, outage and non-outage events, field crews, and devices in the network model.

This implies that an adapter that interfaces between Oracle Utilities Network Management System and multiple mobile data systems and multiple implementations of Oracle Utilities Network Management System and the various individual mobile data systems has to be highly configurable.

To meet this challenge, the Oracle Utilities Network Management System IBM MQ Mobile Adapter can be configured to perform data manipulations and business logic, for flexibility, and has functions commonly used interfacing between Oracle Utilities Network Management System and mobile data systems hard coded for performance.

The core of the configuration is one or more file(s) written in Dynamic Message Language (dml). This language allows the adapter to dynamically generate XML messages from various data sources, and to process XML messages to distribute the data contained in the message to various data sinks.

DML allows data to be textually transformed and combined, has logic to allow XML elements to be included or ignored, and different InterSys API calls to be made, all depending on the data being processed.

The basic units in dml are known as documents. There are two main types of document:

One or more dml files are read by the adapter during initialization. The contents of these files are compiled into a hierarchical set of internal data structures. As the various documents are triggered, the internal data structures are used to generate outgoing XML messages and process incoming XML documents.

The details of the syntax and capabilities of dml are described below in paragraph DML Files and in the Appendices.

An Output Document gathers data from various sources, performs all necessary data transformations and logic, and formats the resulting data into XML elements whose tags are specified in the Output Document. The main sources of data are asynchronous InterSys messages, database selections, data cached in the adapter from previous XML documents, both input and output, and InterSys API calls.

In order to have the resulting XML document generated, the Output Document has to be activated. This activation is known as "triggering" Output Documents. These triggers occur under the following circumstances:

Input Documents process data from elements whose tags are specified in the Input Document. Other elements are ignored. Once the data from all tags in the message that the Input Document recognizes are gathered, all necessary data transformations are performed, possibly in conjunction with data from other sources, and the results are passed to various data sinks. The main data sinks are the database, InterSys API calls, and the adapter cache for use in later document processing.

In order for Input Documents to process the appropriate incoming XML documents, Input Documents have selection criteria. These criteria specify one or more of the following conditions that have to be met before the Input Document is used to process the data in the XML document:

In order for the various dml documents to access Oracle Utilities Network Management System service objects, a number of facilities are available. They include:

Oracle Utilities Network Management System and mobile data systems perform very distinct functions and, therefore have distinct views of a utility. This leads to different object models. The difference that has the major impact on the integration of the two is what appears to be the same object on each side of the interface: events and orders.

Events are associated with particular devices in the electrical network, while orders describe work to be done in the field. Normally, one event is associated with one order, for example when a customer transformer needs to be replaced because of a fault. However, in more complex situations, this one-to-one relationship no longer applies.

An example of this is the series of steps involved in a partial restoration. A typical scenario is presented below:

If a one-to-one relationship were maintained between orders and events, there would now be a new order associated with the downstream switch. However, this does not match the view of the crew in the field. The new event is merely part of the work involved in servicing the original order.

To accommodate this, the adapter will aggregate partial restoration events, if the appropriate configuration options are chosen, into what appears as a single event to the dml. The dml can then process the aggregate event into a single order. Similarly, when the dml processes updates to an order sent by the MDS, causing updates to the aggregate event, the adapter applies the updates to all of the aggregated events in Oracle Utilities Network Management System.

Another example is when the Oracle Utilities Network Management System operator wants to group related events, for example when multiple outages occur in an ice storm in a small area, and assign them to a single crew. The adapter can be configured to treat this in the same way as a partial restoration, but this is not necessarily the preference of the customer. Some mobile data systems can group orders into a folder like object. The adapter can provide a trigger to the dml to process the group of associated events appropriately.

The contents of the configuration files are driven by the information flows required for a particular customer.

This interface is intended to provide for high performance needed to process frequent message exchange such as in the case of a high volume of events during a storm. In order to provide optimum performance, there are aspects of both implementation and usage. Aspects of usage include:

Aspects of implementation which optimize performance include:

The assumption that incoming XML messages are well formed, bypassing the validation step. It is assumed that the sender provided well-formed XML, which was transmitted using reliable communication mechanisms. The actual validation test is whether or not the code that internally parses a message can extract a sufficient set of parameters to process an Input Document. XML that is not well formed will typically generate an error. It should also be noted that XML validation does not necessarily guarantee valid information provided by an external system. If this generates an error in the adapter, the error will be logged.

High-level messages are typically used within Oracle Utilities Network Management System to permit one process to control another process. There are no special high-level messages that would be required for the Generic IBM MQ Mobile Adapter.

Note that doing an Action any.any stop will stop the adapter, which needs to be taken into consideration for administering the adapter when starting and stopping it.

Supported high level messages include the following:

The key objects supported by the adapter include: