Setting up the Process Integration
The following sections describe how to configure integration pack to meet the requirements for two-way integration. Configuration steps include setting the following:
Setting Domain Value Maps for the Integration Layer
Setting Configuration Properties
Various configurations that apply to the entire integration and to specific integration processes are stored in the ConfigurationProperties.xml file located in MDS under the apps/CCB2-MDM2/AIAMetaData/config directory.
These configurations hold several configurable values that are picked up by the integration at runtime to:
Set Default values to be used in the integration.
Activate custom implemented extension points available inside the processes. By default these properties are set to false, not to invoke any of the extension points.
Activate error handling.
Note: Whenever the ConfigurationProperties.xml file is updated, the file must be reloaded to MDS for updates to be reflected in the applications or services that use the updated properties. You can perform the reload by restarting the SOA server.
The ConfigurationProperties.xml file contains two types of configuration:
Module Configurations are the properties that are shared by multiple integration processes within the integration.
Service Configurations are the properties that are used by a specific BPEL process.
Please refer to Appendix B for more information on how to configure the Configuration Properties File values.
Setting Domain Value Maps for the Integration Layer
Domain value maps (DVMs) are a standard feature of the Oracle SOA Suite which maps codes and other static values across applications.
Example: “US” and “USA”.
DVMs are static in nature, though Administrators can add additional maps as needed. Transactional business processes never update DVMs - they only read from them. They are stored in XML files and cached in memory at runtime.
Please refer to Appendix C: Domain Value Maps (DVMs) for a listing of the DVMs included for the integration.
To maintain information within the domain value maps:
1. Open a browser and access the SOA Composer application.
Example: http://soa_host:soa_managerServer_Port/soa/composer/
2. Select the relevant DVM you wish to maintain from the Deployment View pane.
3. To edit the selected DVM, click the Create Session button in the top navigation bar.
4. Once the DVM has been edited, click Save in the navigation bar. This saves the DVM data for that session.
5. Click Publish after updating each DVM. This saves the DVM data in MDS.
Updating MDS
If new artifacts are created, if extensions or customizations are made on the artifacts, or if changes are made to the DVM /or the ConfigurationProperties.xml, you must upload the artifacts to the Oracle Metadata Services (MDS).
The Oracle Metadata Services (MDS) repository contains all the metadata and the contents are stored under <PRODUCT_HOME>/MDS-Artifacts. These are uploaded to <SOA-MDS > apps/CCB2-MDM2. This includes specific schemas, WSDLS, DVMs and ConfigurationProperties.xml.
For more information about updating MDS, see the section “Deployment of MDS Artifacts” in the Installation Guide.
Setting Error Handling for the Integration Layer
Asynchronous Processes
The integration includes two types of errors:
Business Errors – Triggered when the DVM lookup values are not found or there is a transformation error in the integration layer. Business errors are sent back to the source application and can be re-tried from there.
Technical Errors – Triggered when there are connectivity issues between queues. Technical errors are sent to the error queue and can be re-tried from integration layer.
S. No
Integration Process
Type of error
Action
Notification Type
Retry
A1
Master Data Sync – CCB originated request processing
(i.e. SP Information Sync process)
Business error
Message is sent to CCB Response Queue. (i.e CCB SP Response Queue)
Email (optional) and CCB ToDo
Data correction in CCB
A2
 
Technical error
Message is rolled back to CCB Request Error Queue. (i.e CCB SP Request Error Queue)
Email (optional)
Administrator has to move the messages to CCB Request Queue from WebLogic Admin console.
(i.e CCB SP Request Queue)
A3
Master Data Sync – MDM originated response processing
(i.e. SP Information Sync process)
Business error
Message is sent to CCB Response Queue. (i.e CCB SP Response queue
Email (optional) and CCB ToDo
Data correction in CCB
A4
 
Technical error
Message is rolled back to MDM Response Error Queue. (MDM SP Response Error Queue)
Email (optional)
Administrator has to move the messages to MDM Response Queue from WebLogic Admin console. (MDM SP Response Queue)
This is applicable to the Person, SP, SA, Meter, Meter Configuration, and SP-Meter History Information Sync processes.
S. No
Integration Process
Type of error
Action
Notification Type
Retry
C1
Batch BD – CCB originated request processing
Business error
Message is sent to CCB Batch BD Response Queue.
Email (optional) and CCB ToDo
Data correction in CCB
C2
 
Technical error
Message is rolled back to CCB Batch BD Request Error Queue.
Email (optional)
Administrator has to move the messages to CCB Batch BD Request Queue from WebLogic Admin console.
C3
Batch BD – MDM originated response processing
Business error
Message is sent to CCB Batch BD Response Queue.
Email (optional) and CCB ToDo
Data correction in CCB
C4
 
Technical error
Message is rolled back to MDM Batch BD Response Error Queue.
Email (optional)
Administrator has to move the messages to MDM Batch BD Response Queue from WebLogic Admin console.
D1
Online BD – CCB originated request processing
Business error
Message is sent to CCB Online BD Response Queue.
Email (optional) and CCB ToDo
Data correction in CCB
D2
 
Technical error
Message is rolled back to CCB Online BD Request Error Queue.
Email (optional)
Administrator has to move the messages to CCB Online BD Request Queue from WebLogic Admin console.
D3
Online BD – MDM originated response processing
Business error
Message is sent to CCB Online BD Response Queue.
Email (optional) and CCB ToDo
Data correction in CCB
D4
 
Technical error
Message is rolled back to MDM Online BD Response Error Queue.
Email (optional)
Administrator has to move the messages to MDM Online BD Response Queue from WebLogic Admin console.
E1
Replacement Read – MDM originated request processing
Business error
Message is sent to MDM Replacement Read Response Queue.
Email (optional)
Data correction in MDM
E2
 
Technical error
Message is rolled back to MDM Replacement Read Request Error Queue.
Email (optional)
Administrator has to move the messages to MDM Replacement Read Request Queue from WebLogic Admin console.
To retry the technical error failure messages:
1. In the WebLogic console, navigate to Services > Messaging > JMS Modules.
2. Select CCB-MDM Integration JMS Module (CCB2MDM2JM) to display all queues related to this integration.
3. Select the appropriate error queue and click the Monitoring tab. This tab displays the details about messages in the queue in a table.
4. Select the checkbox in the details table and click Show Messages. This displays all the messages in the error queue.
5. Click Move and select Move All.
6. Select the CCB-MDM JMS (CCB2MDM2JS) server to move messages and then click Next.
7. Select the correct parent queue for the error queue from the dropdown and click Finish. This action moves all messages to the source queue, so that the integration layer processes all messages again.
Error Notification Setup
Enable email notification for the error handling module.
1. Login to the Enterprise Manager console.
2. Expand SOA and then right-click SOA Infra. From the menu, click SOA Administration and then click Workflow Properties.
3. From the drop-down list, select EMAIL.
4. Enter the Email IDs in the From address field.
INTEGRATION_ERROR_STORE
The INTEGRATION_ERROR_STORE table is used to store all the error details for each message failure. The table is populated for each integration point based on the BusinessError.NotificationFlag and TechnicalError.NotificationFlag properties for each service in the ConfigurationProperties.xml file.
INTEGRATION_ERR_LOOKUP
The error handling module configuration is governed by the Integration_err_lookup table. This table contains processing instructions for each composite. The Error_Processing_Parent composite picks data for one composite and calls error_Processing_Detail for processing. The configuration in this table is used to process the error records stored in the INTEGRATION_ERROR_STORE table.
S. No.
Column Name
Description
Default/ Suggested values
1
LookUp_ID
Sequence ID of entry in this table. This is auto generated.
Auto generated
2
IP_Name
Name of the composite processed.
Example:
OUMDMOUCCBReplReadReqEBF
This column is pre-populated with the individual enterprise business process name.
Do not modify. Modifying this value will break the code.
3
Processing_Status
Current status of processing must be one of the following:
HALTED (waiting for manual intervention),
NOT REQUIRED
ALIVE
Default: NOT REQUIRED
In order to process the error records, this value must be set to ALIVE.
4
Run_Flag
Processing flag status, Y or N. Unread value = N, read value =Y
N
5
Next_Runtime
Next runtime when the error record should be processed for this composite.
Default: SYSDATE+200
This value needs to be set to the current date or past date to process the error records.
6
Halt_For_Error
Allowed values are Y or N.
When set to Y, manual intervention is required after one successful error record processing and any future errors for that composite will not be processed until some action is taken on that task.
When set to N, processing continues without halting.
Actions that can be performed on the human intervention task are:
ALIVE - This will resume the error processing for all unprocessed records in the INTEGRATION_ERROR_STORE table
ALIVE_FOR_FUTURE_PROCESSING-This will resume the error processing, only for future error records for the composite.
 
N
7
RunTime_Interval
Runtime interval after which the next error
processing should be done.
 
This value must be updated based on the business
requirement. Setting fewer intervals may have
impact on performance.
Example : P0Y0M0DT0H5M0S
Next processing is done after 5 minutes.
Default : P10Y0M0DT0H0M0S
8
Email_ID
EMAIL ID of the person who should be notified about the error by e-mail.
To add multiple E-mail Ids, provide comma separated values.
This value can be different or same for all the composites.
 
Default: email@email.com
9
Email_Content_Type
GENERIC – One Email is sent for all errors. No detail information is included.
SINGLE – One Email is sent for all errors with details included in the attachment.
MULTIPLE – Multiple Emails are sent and each email has information equal to the value specified in Error_Count_Per_Notification column.
Values are case sensitive and must always be given in upper case.
Default: GENERIC
10
Email_XSL
XSL to be applied for creating Email
Content which includes subject/body and attachment. Look and feel can be modified here.
Default file is provided for all the composites and present under the xsl folder of composite.
Example: xsl/Transformation_Create_Email.xsl
Copy this to the mds folder and enter the mds path in this column for additional configuration.
11
Error_Count_Per_Processing
A notification is sent after the number of records set here is processed.
Example: If this is set to 50, then an email notification containing 50 records is sent after 50 records are created in the error store. For every 50 records an email notification is sent.
Default : 100
12
Email_Sent_For_First_Error
On initial install this is set to N. this value gets updated to Y or N while processing.
This field does not need to be updated by the user.
Default: N
13
Email_Attachment_Location
Location where the Email attachment is created on the server.
This value should point to the location/ folder where the attachment should be stored.
This is used to create the attachment file in the following format.
INTEGRATION_ERR_LOOKUP.Email_Attachment_Location + IP_Name + Date (in YYYYMMDDHH24MMSS)
 
14
Email_Attachment_Flag
Y – Send Email with attachment. In this case, it is not mandatory to have Email_Attachment_Location specified.
N – Send Email without attachment, but send the attachment location. In this case, Email_Attachment_Location has to be specified.
ServerName
+INTEGRATION_ERR_LOOKUP.Email_Attachment_Location + IntegrationPoint_Name + Date in YYYYMMDDHH24MMSS
N
15
Publish_Human_Task_Flag
Y – Publish human task
N – Don’t publish human task
If Halt_For_Error value is set to Y and Publish_Human_Task_Flag is also Y, then human task is published and the user can take action from worklist application.
N
16
ID_Human_Task
User/ Group ID to which human task should be published in case Halt_For_Error is set to Y.
This ID must be present in the WebLogic realm pointed by fusion middleware.
weblogic
17
Last_Updated_Date
Last updated date time
SYSDATE
18
Purge_Error_Store_Flag
Y – Purge data
N – No purge require
The process PurgeIntegrationErrorStore is deployed when the flag, purge.process.deploy=true (in the deploy.properties file) is set to true during installation.
If flag.purge.process = false, then value of this column Purge_Error_Store_Flag will always be N.
Default : N
19
Purge_Processing_Status_Flag
Y – Purge Processing in process
N – Purge processing not happening
The process PurgeIntegrationErrorStore is only deployed when the flag, purge.process.deploy=true (in the deploy.properties file) is set to true during installation.
If flag.purge.process = false then value of this column Purge_Error_Store_Flag will always be N.
Default : N
20
Purge_Frequency
No of days after which data should be purged. This will be in picture format
Example : P10Y0M0DT0H0M0S
Next processing will be done after 10 years 0 months 0 days 0 hours 0 minutes and 0 seconds.
This value has to be updated based on the business requirement. Setting fewer intervals may have impact on performance.
Need to set this value as appropriate.
Applicable only when flag.purge.process = true in deploy.properties file during installation and the process PurgeIntegrationErrorStore ID deployed.
Default : P10Y0M0DT0H0M0S
21
Next_Purge_Date
Next purge date. Format: Next_Purge_date + Purge_Frequency
Applicable only when flag.purge.process = true in deploy.properties file during installation and the process PurgeIntegrationErrorStore ID deployed.
SYSDATE+100
22
Purge_File_Name
Directory name where the purge file should be stored.
Applicable only when flag.purge.process = true in deploy.properties file during installation and the process PurgeIntegrationErrorStore ID deployed.
'location on server where purge record should be persisted'
To customize Error Email Notifications for individual integration points:
The values can be directly updated in the INTEGRATION_ERR_LOOKUP table. Alternatively, the composite can be used as:
1. Use the composite: UpdateIntegrationErrorLookupTable.
2. Open the following URL in a browser to get the screen that provides options to update the contents of table.
http://<hostname>:<soa server port>/soa-infra/services/CCB2-MDM2/
UpdateIntegrationErrorLookupTable/updateintegrationerrorlookuptablebpel_client_ep?
a. Expand WS-Security and provide authentication information. This username and password are going to be same as that used to log in to WebLogic Enterprise Manager console.
b. Expand the paylod section. This displays several editable text fields. Only the ipName field is mandatory and should be entered as one of the values from INTEGRATION_ERR_LOOKUP.IP_NAME field.
By default, all the checkboxes appearing next to the text fields are selected.
c. Provide values in the text field. If you do not want to have a particular value updated, then uncheck the box.
Synchronous Processes
s
Any exception or error thrown by the integration service is sent back to Oracle Utilities Customer Care and Billing as a SOAP Fault or exception which will change the outbound message status to be in ‘Error’.
Integration service will also send back the exception or SOAP fault received from Oracle Utilities Meter Data Management to Oracle Utilities Customer Care and Billing. This will also change the outbound message status to be in ‘Error’
No email notifications for Business and Technical errors will be sent out from the integration service.