Previously, on the topic of communication between multiple systems, we looked at methods of intercommunication between SSP Lifecycle Work and ArcFM™ Designer. In that article, we largely focused on direct database edits and Web Services. But the example we used was living entirely within the client’s network, with both systems sharing a trusted space. Lifecycle could update Designer, Designer could update Lifecycle through COM class customization, everything is nice and straightforward.

Let’s look at a different example of integrating two different applications: Interactive Voice Response (IVR) and Outage Management System (OMS). In the world of real-time outage updates, circuit tracing, and beyond, it only makes sense to get these two systems talking. However, our IVR vendor has their own server, the IVR software cannot live on the same server as our OMS.

• Direct Database Edits: This level of interoperability is going to be heavily dependent on the vendor. Many vendors will work with clients to customize their solutions to the client but may charge a premium for such services, as customization can be risky for a product-centric vendor. This may be a barrier for smaller utilities/municipalities.
• Web Services: Web Services, specifically, Web Services communicating via SOAP protocol (XML) is a time-honored means of allowing data transfer between utility software, to the point where the MultiSpeak Specification was developed to standardize message formats between utility software. Using a standardized format for communication allows for Commercial-Off-The-Shelf products to handle potentially complex operations in a configurable fashion.

We touched on Web Services in the previous article, but spent more time discussing the ins-and-outs of the process schema in Designer. By exposing Web Services, we allow many different applications to interact with each other in a secure and controlled fashion. Returning to the MultiSpeak Specification, they have an extensive list of vendors whose software is MultiSpeak-complaint, streamlining the translation process between sender and receiver.

Here’s an example of an outage notification call coming from IVR (download .txt file here!):

The SOAP Envelope contains a Header, which usually includes authentication information, and the body, which contains the actual data we’re trying to transmit. In this case, we’re transmitting an ODEventNotification message from IVR.

The ODEventNotification class contains the relevant information needed to create an outage in OMS, including the customer account information, customer callback information, time/date details, and it’s even extensible through the “extensionsList” node. If your shop uses MultiSpeak-compliant solutions for both IVR and OMS, these may already be integrated.

Otherwise, it’s time to create a Web Service that exposes endpoints that can receive the MultiSpeak message from IVR.

You need a MultiSpeak WSDL (?.wsdl, Web Service Description Language – it’s a full class library with a namespace in XML format). Typically message objects come in a wrapper class with a header and a body like we see in the example above. Visual Studio and Eclipse both can consume a WSDL and create the represented namespace in an object-oriented language such as C# or Java, and similar packages exist for other IDEs and languages.

We will then expose an endpoint in our Web Service like so:

Once the ODEventNotification object is received, our Web Service can then pass the request along to a Data Service class which will update OMS with the outage details sent from IVR. This allows for customization of how to translate customer inputs (outage severity, location, account information) into creating the correct nature of outage. This is also a potential point of integration with the Customer Information System (CIS) (eg. CIS notes indicate reporting customer was doing pool excavation and called 811 to get lines marked – this may trigger a different sort of OMS response than the 4^th caller from a service area with a known blown transformer).

In the case of a .NET integration, our Web Service will probably be represented as a .svc or .asmx address, hosted in IIS. The Data Service class will then interact with any points of extensibility in the OMS software to create the outage incident, or simply… make a direct database insert. This had to somehow end up in the OMS database, didn’t it?

The response, ODEventNotificationResponse, also has that same SOAP Envelope format: header and body. The body in this case is simply an array of error objects. As the Request is processed through the Data Service, errors can be caught and returned to the Web Service to indicate a failure to IVR, and a successfully processed outage notification would return an empty array.

This is just one example of integrating 2 utility applications through MultiSpeak-compliant Web Services, and specifically for Outage Management operations. MultiSpeak also covers Metering, EPC, Demand Response, Billing/PAN, Accounting – it’s a very robust standard. Project statuses may be updated, outage statuses requested, work locations changed, account balances checked – modern electric operations handle a lot of operations, and we can use MultiSpeak SOAP envelopes to communicate a lot of them.

In conclusion, we have demonstrated how Web Services can be used to integrate different applications used by utilities/municipalities without the need for large-scale customization.