8How the Connector Performs a Service Region Data Transfer
How the Connector Performs a Service Region Data Transfer
This chapter describes how the connector performs a service region data transfer. It includes the following topics:
Overview of How the Connector Performs a Service Region Data Transfer
The integration flow that performs a service region data transfer allows you to migrate existing service regions and associated employees and eligible activities to an Oracle Real-Time Scheduler Service Area. You can also use this integration flow to migrate a new service region to Oracle Real-Time Scheduler. The new service region is scheduled in Siebel Scheduler along with employees who are associated with the new service region.
When the Service Region transfer is complete, the corresponding Service Area created in Oracle Real-Time Scheduler should be manually associated to respective Scheduler Area in Oracle Real-Time Scheduler.
Integration Flow That Performs a Service Region Data Transfer
The following illustrates the integration flow that performs a service region data transfer. For more information, see the following topics:

Explanation of Callouts
The integration flow that performs a service region data transfer includes the following steps:
Siebel CRM calls the Web service that starts the process. It supplies to this Web service the Id of the service region that this integration must transfer. This Id is the ROW_ID of the service region in the Siebel database. Siebel CRM uses Simple Object Access Protocol (SOAP) over Hypertext Transfer Protocol (HTTP) to make this call.
The Business Process Execution Language (BPEL) flow sets the value of the Synchronization Status field of the service region record to Migration to ORS in progress. To perform this work directly on the Siebel database, it uses a database adapter that is connected to the Siebel database.
The BPEL flow extracts the name and description of the service region from the Siebel database. To query the Siebel database, it uses a database adapter that is configured in query mode and it uses the service region Id as the query specification.
To create an Oracle Real-Time Scheduler Service Area, the BPEL flow makes Web Service calls to Oracle Real-Time Scheduler.
Extracts all data that is related to the employee from the Siebel database. To extract all employee data, this flow joins all the relevant Siebel database tables. This data includes details of the start address, end address, associated skills, associated time zone, and so forth. It does not extract the following employee records:
Employee records that contain Y in the ORS sync flag
Employees records that contain a scheduling availability end date that occurs prior to the next day of the system time that is in effect during the data transfer
Reads the first employee record and determines the start address and end address based on the Start Shift From and End Shift At employee fields. If the values for these fields are Home, then the integration will consider the Home address. If the value of these fields is Depot, then the integration will consider the Depot address.
The integration also validates whether the start and end address have latitude and longitude values.
If the address records are not present, then this integration does not synchronize the employee record in the Siebel database with the ORS database. Instead, it saves a synchronization error in the employee record in the Siebel database. This error states that the start address and the end address are missing.
This integration will insert the Employee record along with Start and End Address, Employee Skills, and Employee Exception Hours into the ORS database by calling the UPSERT_EMPLOYEE method of the AdminDataManagement_EBF composite.
Note: By default, all Leaves and POUs of synchronized employees from Siebel are sent to ORS. If these are to be ignored, please refer to configurations as described in Configurations to Determine Source of Leaves and POUs.Repeats Step 6 for each subsequent employee record until it finishes processing all employee records.
After this flow processes all employee records, the BPEL flow gets the activity records and associated data from the Siebel database, except for activities that meet any of the following conditions:
Any activity in the service region whose ORS synchronization status is N and the status is not Done, Cancelled, or Completed.
Any activity that is expired. An activity is considered not to have expired if any of the following situations are true:
The latest start date for the activity will occur at any time in the future.
The latest start date is null.
The planned end date will occur in the future.
The planned end is null.
This integration considers any time that occurs after the system time that is in effect during the data transfer as a future date.
To write data for each activity record to the ORS database, it uses the Upsert_Activity operation of the AppointmentBookingSystemSBLORS_EBF composite. This flow uses a native binding to the AppointmentBookingSystemSBLORS_EBF composite.
Saves the result of the synchronous call in the Siebel activity record.
Saves the overall status of the data transfer in the Synchronization Status field of the Service Region. It uses the following logic:
If this flow successfully transfers all employees, addresses, and activities, then it does the following work:
Sets the Synchronization Status field to the following value:
>>>>>Successfully migrated to ORS
Inserts the following value in the Engine field:
>>>>>ORS
If this flow cannot successfully transfer at least one employee, address, or activity, then it does the following work:
Sets the Synchronization Status field to the following value:
>>>>>Partially migrated to ORS
Inserts the following value in the Engine field:
>>>>>ORS
If this flow encounters an exception, then it does the following work:
Sets the Synchronization Status field to the following value:
>>>>>Transfer to ORS aborted due to exception
Does not change the value in the Engine field
How Siebel Field Service Integration to Oracle Real-Time Scheduler Avoids Network Overhead
Reading the Siebel database and updating the employee records, address records, or activity records for each individual record causes network overhead. To avoid this situation, this integration uses a domain value map (DVM) parameter that contains a counter. As long as the counter remains less than a threshold, the service region data transfer flow appends the input of the calling activity with the synchronization message. If the counter reaches the value specified in the parameter, or if it is the last record, then this flow writes all the updates to the Siebel database in a batch.
DVM That Performs a Service Region Data Transfer
DVM | Description |
---|---|
SBL_ORS_Parameter_Definition.dvm |
This integration uses the following DVM parameters:
|
Composite This Integration Uses During a Service Region Data Transfer
This integration uses the following project to perform a service region data transfer:
ServiceRegionCutoverToORS_EBF
This project supports multiple daylight savings rules.
Web Services That Perform a Service Region Data Transfer
This topic describes Siebel Web services that perform a service region data transfer.
Outbound Web Service That Performs a Service Region Data Transfer
Web Service Name | Proxy Business Service Name |
---|---|
Serviceregionmigrationorch+ estrator_client_ep |
ServiceRegionMigrationOrchestrator |
Name | Data Type | Integration Object Name | Type |
---|---|---|---|
ServiceRegionMigrationOrchestratorRequestMessage: payload |
Integration Object |
input |
Input |
Integration Objects That Perform a Service Region Data Transfer
Integration Object Name | Business Object | Type |
---|---|---|
input |
Not applicable |
XML |
Integration Component | Business Component | Parent Integration Component |
---|---|---|
input |
input |
Not applicable |