X

Announcements and Technical Advice for the Oracle
Utilities product community from the Product Management team

  • July 12, 2019

Saving Costs with Middleware Integration

Anthony Shorten
Senior Principal Product Manager

Over my career over (ahem)... 30 years, I have seen integration technologies come and go with varying levels of success. One of the most persistent and more successful integration technologies has been Middleware. In basic terms, middleware sits in the middle (hence the name) between the source and target applications in an integration. It liases with a transport method, the way the source delivers the payload to the target and may translate the payload into a format that the target supports, if necessary. It can also deal with the response, or lack of, from the target for the source. The figure below summarizes this relationship:

Summary of Middleware

While most people associate costs with purchasing middleware, I personally find the benefits tend to reduce the costs significantly in any implementation. There are a number of reasons why middleware is very cost effective:

  • Simplify Your Integration. Middleware is flexible in the transports supported between the source and target applications. This means there are flexible ways of delivering payloads between application in both asychronous and synchronous modes.
  • Scalability To Your Volume. Most middleware are based upon scalable and highly available architectures allowing you to support the full range of volumes and service levels.
  • Isolates Targets and Sources. Source and Target applications need to concentrate on delivering superior functionality rather than worrying about how to deliver payloads. By integrating to middleware, the applications then are free to share their functionality across application data topologies. This is particularly important in the cloud where the services should concentrate on being superior services and let integration be best served by integration services. For on-premise implementations, middleware can isolate the technical aspects of an integration and act as a proxy to reduce costs in change.
  • Flexible Payload Formatting. Source and target applications cannot be assumed to talk in the same structures. Therefore translation to and from payload formats may be necessary. Middleware products support a wide range of formats and translation languages (both simple and complex). Again isolating the payloads saves development costs in the source and target applications and hides that complexity in the middleware.
  • Simplifies Error Detection. One of the most underestimated benefits of middleware is acting as an error hospital when integration goes wrong. being able to use the middleware to help poinpoint an issue in integration is critical. In some cases, you can configure the middleware to handle the exception automatically for you to further reduce costs.

Partners have asked me for advice on reducing their costs in integration and I usually point out that the introduction of a middleware oriented architecture as the central conduit for integration is ideal for most situations. Certainly Oracle supplies a number of cloud and on-premise solutions and the products are open enough that they can be used or alternatives that support the relevant industry standards.

Oracle offers a wide range of middleware solutions that can be used with on-premise and Oracle Utilities SaaS Cloud implementations. The most common of these are:

The figure below illustrates the integration with the Oracle Utilities Application Framework:

Integration with middleware

The main points of contact with Oracle Utilities Application Framework can be summarized as follows:

  • Inbound Web Services. This is the premier method for inbound integration using either SOAP or REST based services using Inbound Web Services. This also supports WS-Policy for security and registries for integrations. XML Application Integration is not supported for newer customers and cloud customers. Customers should migrate using the guidelines in Migrating from XAI to IWS (Doc Id: 1644914.1) available from My Oracle Support.
  • Staging (Upload and Download). Using native database or Inbound Web Services to push data into the product/service or extract data from the product/service.
  • Outbound Messages. Allowing real time (and batch) integration upon business events.
  • SQL Access (on-premise only). Using the native database adapters in middleware to extract data in various formats.

Middleware does cost money but the benefits it brings in terms of cost savings and simplifying your architecture can realize benefits beyond the license value.

For more information about integration refer to Oracle Utilities Application Framework Integration Overview (Doc Id: 789060.1) available from My Oracle Support.

Join the discussion

Comments ( 3 )
  • Enrico Buenaventura Wednesday, August 7, 2019
    This is the approach that we are adopting in EA for market transaction messaging. For outbound transactions, as far as CC&B is concerned it is just pushing customer, site, or meter data to a queue with a payload that doesn't have to necessary be 100% compliant with the market schema. It will be the responsibility of the integration platform to handle the payload data transformation, the bundling of the messages if this is required, and the routing of these messages to the market hub. For inbounds, CC&B will expose services that an integration platform can call to process inbound B2M and B2B transactions and the ACK or NACK response will be managed by the integration platform based on the CC&B response to the web service call. This prevents CC&B from becoming the "market hub" for other applications that integrates with CC&B like MDMS, CRM and/or an external Credit and Collections Engine.
  • Sam Wednesday, October 9, 2019
    I see SQL Access (on-premise only). If our CCB moves to the cloud, how can our Oracle SOA Suite CS access the data in our instance? Is it just through web services?
  • Anthony Shorten Wednesday, October 9, 2019
    SQL Access is usually not recommended for outbound (unless you are using the OSB Adapters). Web Services are the best method for both inbound and outbound from the Cloud. Ideally the Integration Cloud has this all built in and is the recommended way of using it. SOA CS would use the Web Service methods or Batch (for triggers) on Object Storage.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.