Technical Overview
This is a direct integration between Oracle Utilities Customer Care and Billing and Oracle Utilities Meter Data Management.
This section provides technical information about the integration that uses the following types of end-to-end integration processes:
Asynchronous Processes
Most of the end-to-end integration processes are asynchronous. These integration processes receive messages from JMS queues and send messages to JMS queues. Oracle Utilities Customer Care and Billing and Oracle Utilities Meter Data Management have the ability to read messages from JMS queues, and then write the processed messages to JMS queues.
The following end-to-end integration processes are asynchronous:
• Person Information Sync Integration
• SP Information Sync Integration
• SA Information Sync Integration
• SA Relationship Synchronization
• Meter Information Sync Integration
• Meter Configuration Information Sync Integration
• SP-Meter History Information Sync Integration
• Scalar Meter Read Sync Integration
• Dynamic Option Synchronization
• Dynamic Option Event Synchronization
• Batch Bill Determinant Integration
• Online Bill Determinant Integration
• Replacement Reads Integration
• Bill Cycle Synchronization
WebLogic JMS is used as a queuing mechanism in the integration layer. For each integration process there are 8 JMS queues with the exception of the replacement reads process which does not have a response process.
Queue | Description | |
1. | Source application request queue | Source application adds messages to this queue, which is then picked up by the integration layer for transformation. |
2. | Source application response queue | Business errors in the integration and success or failure acknowledgments from the target application are transformed by the integration and written to this queue The source application will read the message and process it. |
3. | Source application request error queue | The corresponding error queue of the source application request queue where the request messages are moved when the target application request queue is unreachable after a set number of retries has been reached or when integration encounters a technical error. |
4. | Source application response error queue | The corresponding error queue of the source application response queue where the response messages are moved when the source application rollsback the message when it encounters a technical error or fault. |
5. | Target application request queue | Integration reads messages from the source application request queue, transforms them, and writes them to this queue. The target application will read the message and process it. |
6. | Target application response queue | Success or failure acknowledgments from the target application are written to this queue and are read by the integration. |
7. | Target application request error queue | The corresponding error queue of the target application request queue where the request messages are moved when the target application rollback back the message when it encounters a technical error or fault. |
8. | Target application response error queue | The corresponding error queue of the target application response queue where the response messages are moved when the source application response queue is unreachable after a set number of retries has been reached or when integration encounters a technical error. |
• Two BPEL processes manage each integration process: one for the request processing and one for the response processing.
• The Request BPEL process includes the following:
• JMS Consumer to read from source request queue
• JMS Producer to write to the target request queue
• Transformations to convert messages from source format to target format. DVMs are used for the data transformation.
• Error handling and optional error notification when configured
• The Response BPEL process includes the following:
• JMS Consumer to read from the target response queue
• JMS Producer to write to the source response queue
• Acknowledgement transformations to convert messages from the target format to the source format. DVMs are used for the data transformation.
• Error handling and optional error notification when configured
• The JMS consumer and BPEL process is configured to participate in a global transaction, so that BPEL process can issue rollback and commits on the queue. The BPEL process issues rollbacks on the queue in the scenario where it is not able to reach the target queue and the message is moved to the corresponding error queue.
• All technical errors encountered in the integration layer will issue a rollback and move the messages to the corresponding error queue of the queue from which the message has been consumed.
Note: Whether Oracle Utilities Customer Care and Billing or Oracle Utilities Meter Data Management is the source or target application or vice versa, these edge applications need to setup their JMS and MDB configurations to send and receive messages to and from the queues. Refer to Chapter 3: Configuration Guidelines for Oracle Utilities Customer Care and Billing and Oracle Utilities Meter Data Management - Inbound Message Configuration and Outbound Message Configuration.
The following diagram provides a graphical representation of this processing:
Synchronous Processes
Some of the end-to-end integration processes are synchronous. These integration processes are exposed as a web service and receive the request and send the response back to the caller. The following end-to-end integration processes are synchronous:
• Get Register Read High-Low Boundaries
• Get Usage Request
• Usage Adjustment Request
• SA Activation Bill Cycle Request
• Bill Cycle Change Notification
• Usage Transaction Info Update
One BPEL process manages each integration process and the BPEL process is exposed as a web service.
• The BPEL Process handles the following:
• Transformations to convert messages from source format to target format. DVMs are sometimes used for the data transformation.
• Transforms the request message coming from the source application (Oracle Utilities Customer Care and Billing) to the target application’s (Oracle Utilities Meter Data Management) format.
• Transforms the response message coming from the target application (Oracle Utilities Meter Data Management) to the source application’s (Oracle Utilities Customer Care and Billing) format
• Invokes Oracle Utilities Meter Data Management service synchronously to pass the formatted request message.
• Receives the response message coming from the target application (Oracle Utilities Meter Data Management)
• Message extensions:
• If the extension point flag (Extension.PreXformCCB2toMDM2) is enabled, it will invoke the PreXform CCB to MDM Custom Extension Service.
• If the extension point flag (Extension.PostXformCCB2toMDM2) is enabled, it will invoke the PostXform CCB to MDM Custom Extension Service.
• If the extension point flag (Extension.PreXformMDM2toCCB2) is enabled, it will invoke the PreXform MDM to CCB Custom Extension Service.
• If the extension point flag (Extension.PostXformMDM2toCCB2) is enabled, it will invoke the PostXform MDM to CCB Custom Extension Service.
• The extension point flags are defaulted from the Configuration properties file.
• Custom extension xsl templates are also provided for additional mapping.
• Any exception encountered by the integration will send back a SOAP Fault to Oracle Utilities Customer Care and Billing. This includes technical errors (such as connectivity errors) and transformation errors.
• Any exception or faults that the integration receives from Oracle Utilities Meter Data Management is sent back to Oracle Utilities Customer Care and Billing.
The following diagram provides a graphical representation of this processing:
JMS Wrapper Services For Async Processes
The JMS Wrapper processes interact with the edge applications through web services.
There are two types of JMS Wrapper processes:
• The JMS Write Process
This process is exposed as a web service, so the edge applications can communicate with the corresponding asynchronous integration process through webservice calls and do not need to access the queues directly. These are referred to as the JMS Wrapper services.
The edge applications send their messages by invoking the Integration Point's JMS Write process which will receive the message and write it to the source queue or target response queue.
The edge applications send their messages by invoking the Integration Point's JMS Write process which will receive the message and write it to the source queue or target response queue.
• The JMS Read process
This process consumes the message from the queue and invokes the edge application's webservice to send the message to the application.
The Integration Point's JMS Read process consumes the message from the target request queue or source response queue and sends it to the corresponding application by invoking the application's webservice.
The main asynchronous integration processes should still work as is. The only change here is how the messages are written and consumed by the edge applications.
When integrating with Oracle Utilities Customer Cloud Service (OUCCS) and Oracle Utilities Meter Solution Cloud Service (OUMSCS), the JMS wrapper processes should always be used to access the asynchronous processes.
The following diagrams provide a graphical representation of the end to end processing:
Note: JMS Wrapper processes are optionally installed to make the JMS process contained inside the SOA layer.
The following diagram provides a visual representation of the JMS wrappers for asynchronous processes: 