This appendix discusses the delivered Business Process Execution Language (BPEL) business processes and web services, and provides guidelines on how to view message elements.
See Also
This section discusses:
Communications New Order process flow.
Mobile Number Portability process flow.
Change Service process flow.
Prepaid to Postpaid Account Conversion process flow.
Port Authorization Code (PAC) Request process flow.
Service Management Activate Service process flow.
Service Management Suspend Service process flow.
Service Management Suspend and Change Service process flow.
Service Management Resume Service process flow.
Service Management Disconnect Service process flow.
Lost or Stolen Handset process flow.
Service Management Port In process flow.
Convergent Order Synchronization process flow.
New Account Creation process flow.
Use of sub and stub business processes in delivered business processes.
This process is initiated when an order for communications is created and submitted after passing through any holds. Payload is created with order details in it and is passed onto this business process as part of the initiation process, which is illustrated in the following graphic:
Communications New Order process flow for handling tasks and updates in CRM and fulfillment systems (1 of 2)
Communications New Order process flow for handling tasks and updates in CRM and fulfillment systems (2 of 2)
Note. If this is a storefront transaction, change the source from Phone to Storefront to ensure the correct New Order flow is used. A storefront order skips shipping and does not go to fulfillment. In other words, if the source of an order is storefront, the Communications New Order business process calls the Activate Service business process automatically as part of its processing. For other source values, the Activate Service business process is not triggered automatically within the Communications New Order business process. The Activate Service business process is triggered upon the submission of a service management order, typically after the customer has received the shipment and calls in to activate the service.
When this business process is initiated, it:
Checks if the new order that is be created is a child order of a convergent order.
If yes, any new billing account is to be created at the context of its parent convergent order. In other words, new accounts are not created as part of the Communication New Order process instances that are invoked for child orders.
If no, any new billing account (if requested in the order) is to be created at the context of the new order.
If the account should be created at the context of the parent convergent order, the process determines if it should wait for the New Account notification message from the parent Convergent Order Synchronization process flow before moving on to the next step.
If the account should be created at the context of the new order, the process checks if the New Account option is enabled in the order.
If the option is enabled, the process then triggers the New Account Creation subbusiness process, which performs customer credit check and creates billing accounts. If the option is not selected or when the New Account Creation subbusiness process is completed, the Communication New Order process goes to the step where proper installed products and relationships are established with the Pending status.
Checks if the convergent order synchronization process needs to be invoked.
Note. This step applies to multilevel product bundles. This process is required if there are product components that are migrated from an existing contract to this new contract to be created by this new order process instance, which is currently put on hold until the installed source contract has been set in pending status. The new order process instance resumes once it receives a notification from the synchronization process.
Creates installed products for all products available in the order with the appropriate relationships through an internal web service call.
This step also supports the creation of installed products for orders that contain split billing products.
If the order contains commitment products, this step creates installed commitments and commitment contracts for them in the Pending status. In the case where the customer of this order has other concurrent orders in the system, its pending installed commitments are considered active. It is because when an installed commitment is in a pending status, the system allows service management orders to be created for installed products that may impact the pending installed commitment, which includes extending, renewing or canceling the commitment. Therefore, the Controller application considers pending installed commitments active so that it can take proper steps to handle these kinds of impacts for installed commitments, for example, adding or updating the corresponding installed links.
Important! For multilevel product bundles, this step creates installed links between multilevel installed products as required by the configuration. The reference to the original order line relationship is stored in the installed link as well. If the new order is a target order of a product component migration, this step also performs migration-specific actions for migrated installed products, for example, creating a child of link between the migrated installed product (commercial component) to the new commercial parent, creating a sells link between the migrated installed product (functional component) to the new commercial atomic offer, or changing installed product information (owner, installation site, or billing account).
Notifies the convergent order synchronization process.
Note. This step is applicable only if the current order has sibling orders (from the same parent convergent order) that are dependent on it. For example, in a convergent order where two products with the brings and removes line relationship, the target child order depends on the source child order and a brings and removes installed link cannot be established as installed until the installed products for both child orders are created.
Cumulates the information for all the line items that require shipment.
This information is published to an external fulfillment system through an external web service call.
Receives the shipment notice from the external fulfillment system.
This notice can contain one or many lines. The business process waits for all the shipment information, which can be returned in multiple batches from the external system.
Updates the corresponding installed product (that is, the serial ID) for each received shipment notice.
This is done through an internal web service call.
Updates the corresponding order line status to Shipped for each received shipment notice.
Checks if the payment method selected for nonrecurring charges is by billing account.
If yes, the process sends the billing system details about the nonrecurring payment.
If no, go to the next step.
Performs these activities for each line item in the order if the nature of the product in the line item is Wireless:
If the category of the product is SIM (Subscriber Identity Module):
i. The process relates the corresponding phone numbers (which are related to the line item to which this SIM is associated) to this SIM, through an internal web service call.
ii. The SIM status is set to Active.
If the category of the product is Phone, the phone number status is set to Pending Activation.
If the line item has a port-in request, the Mobile Number Portability business process is invoked.
After the completion of the Mobile Number Portability business process, the control is returned to this business process.
If the line item is associated with a subbusiness process, a call to the subbusiness process is made and the control is returned to the main calling business process.
All line-level activities are completed.
Creates service orders for installed products, if applicable, through an internal web service call.
Creates an agreement for the order, if applicable, through an internal web service call.
Sets the order status to Completed through an internal web service call, which also sets the status of all lines to Completed if they are not already in the Completed, Shipped, or Cancelled status.
Important! For multilevel product bundles, this step is performed after the BPEL process has identified line items that require shipping.
If any of the line items requires shipping, sets the status of the parent installed product to Pending Call Activation through an internal web service call, which also takes care of updating the status of all child installed products to Pending Call Activation.
If no line items require shipping, invokes the Service Management Activate Service business process.
After the Service Management Activate Service business process is completed, the control is returned to this main business process.
The Communications New Order business process ends.
While this business process is in progress, a cancellation message is sent to it if the corresponding new order is being cancelled. When that happens, the business process terminates regardless of the stage it is in.
This process is typically initiated from the Communications New Order business process. For each port-in found on an order, an instance of this process exists. This process is responsible for validating the details provided for the port-in and is illustrated in the following graphic:
See Communications New Order Process Flow.
Mobile Number Portability process flow initiated from the Communications New Order process (1 of 2)
Mobile Number Portability process flow initiated from the Communications New Order process (2 of 2)
When this business process is initiated from the Communications New Order business process it:
Examines the payload for the port-in details.
If the details indicate that a system validation is needed, the process calls a third-party service to validate the porting details. Otherwise, it assumes that the details are validated already.
If system validation is needed, sets the order line status to 1200 : Port-In Processing if its current status is 1000 : New.
This is accomplished by calling a delivered service operation.
A loop is performed until either the port-in details become valid or the maximum number of Retry Attempts (default = 3) is reached. Then it:
Calls the RB_CUSTOMER_GET_CUSTOMER (Get Customer Information) service operation of the delivered Customer web service to retrieve customer details.
If the order has a contact BO (business object) ID, the ID is used to obtain customer information. Otherwise, the customer BO ID is used.
Copies all needed customer details and payload data into the Port Request message.
Calls the third-party web service (it is a placeholder that customers need to replace with their own web services) for the port-in request.
The purpose of this routine is to validate the details and respond with the validation results. This is an asynchronous call.
Receives a response from the third-party system and checks for the validity of the details.
If the details are valid, it:
i. Calls a delivered web service to update the order line status to 1230 : Port In Validated.
ii. Returns to the top of the loop with the details marked as valid.
If the details are invalid, it:
i. Calls a delivered web service to update the order line status to 1210 : Invalid Port-In.
ii. Calls the RO_SERVICEMGT_ADDNOTE service operation to add a note with the validation message that is returned from the third-party system.
iii. Calls the CREATE_WORKLIST_ITEM service operation to add a worklist entry for this order, indicating that the port-in details are invalid.
At this point, the process waits until a manual update of the worklist item takes place, which typically happens after a customer service representative makes the necessary changes to the port-in details on the order and resubmits the order.
iv. Increases the retry count by 1 after the worklist notification is received and returns to the top of the loop to try again.
If port-in details are valid, it calls the RO_SERVICEMGT_ADDSUBMIT service operation to create a service management order (with Port-In action) and have it submitted, which launches the Service Management Port In business process to continue the porting procedure.
Copies the input payload to the output data.
Notifies the Communications New Order business process that the Mobile Number Portability business process is complete.
The Mobile Number Portability business process ends.
Note. If the MNP order is cancelled, the status of the installed products does not change.
This process is initiated when a service management order for communications is created with a line action of Change. Also, it gets initiated from the Service Management Suspend and Change Service business process as a subbusiness process.
See Service Management Suspend and Change Service Process Flow.
The following graphic illustrates the Change Service process flow, which performs necessary tasks for change-related service requests such as changing phone numbers, removing products, adding products and update attribute information:
Change service process flow (1 of 5)
Portion of the change service process flow for removing products (2 of 5)
Portion of the change service process flow for changing phone numbers (3 of 5)
Portion of the change service process flow for updating installed products in convergent orders (4 of 5)
Portion of the change service process flow for adding products and updating respective statuses (5 of 5)
When this business process is initiated, it:
Checks if the new service management order that is be created is a child order of a convergent order.
If yes, any new billing account is to be created at the context of its parent convergent order. In other words, new accounts are not created as part of the Change Service process instances that are invoked for child orders.
If no, any new billing account (if requested in the service management order) is to be created at the context of the new service management order.
If the account should be created at the context of the parent convergent order, the process determines if it should wait for the New Account notification message from the parent Convergent Order Synchronization process flow before moving on to the next step.
If the account should be created at the context of the new service management order, the process checks if the New Account option is enabled in the service management order.
If the option is enabled, the process then triggers the New Account Creation subbusiness process, which performs customer credit check and creates billing accounts.
Checks if the payment method selected for nonrecurring charges is by billing account.
If yes, the process sends the billing system details about the nonrecurring payment.
If no, go to the next step.
Checks if the first line item of the service management order has an action of Change or SuspendAndChange.
Note. Steps 6 through 9 are line-level activities.
Checks if any line item is for a multilevel product component.
All multilevel product components line items are processed in a single flow, in other words, these components are updated as a whole in one single step to sustain the integrity of the multilevel product bundle. Updates include operations on the installed links and installed product attributes.
If yes, continue to check if the multilevel installed product is a top-level component in its multilevel product bundle. Processing for multilevel product components is initiated from the top-level component order line.
The system first checks if the convergent order synchronization process needs to be invoked. This process is required if there are product components that are migrated from an existing contract to this contract to be updated by this change service process instance, which is currently put on hold until the installed source contract has been set in pending status. The change service process instance resumes once it receives a notification from the synchronization process.
Next, it sets the statuses of installed product and installed link to the Pending status, and updates the attribute values for the installed product that are captured in the configuration session. If the change action includes changing an attribute or changing an outgoing link of an installed product, the change service process (the SetPendingStatus step) calls the MLPBModifyService web service to set the corresponding installed product status to Pending Modification. When the update is complete, the SetInstalledOrDisconnectStatus step calls the same web service to set the installed product status to Installed. It also captures any change in billing account assignment for installed products that are split billing-enabled.
In the case of a change of service for an installed commitment, the same status update applies the installed commitment, its installed links and its commitment contract, followed by an update to the start and end dates of the commitment contract.
If the service management order is a target order of a product component migration, this step also performs migration-specific actions for migrated installed products, for example, creating a child of link between the migrated installed product (commercial component) to the new commercial parent, creating a sells link between the migrated installed product (functional component) to the new commercial atomic offer, or changing installed product information (owner, installation site, or billing account).
Then, it notifies the CO (convergent order) synchronization process, which checks again if synchronization is required for this order. The synchronization process is required in the case where some installed links sourcing from the current order mandate that some pending installed products (in other child orders of the same convergent order) have to be created first. After the synchronization process completes, it sends a notification to the change service process instance, a message is sent to provisioning system about the updated multilevel installed product. If synchronization is not required, the message is sent to the provisioning system without awaiting any notification.
Subsequently, the statuses of installed products and installed product links are updated based on the selected line or line relationship action, followed by the update on pricing of the service management order and phone number status, if the installed product is associated with a phone number. Lastly, the Change Service process sets the status of the service management order to Complete.
Note. In the case of a change of service for an installed commitment, the same status update applies the installed commitment, its installed links and its commitment contract, followed by an update to the start and end dates of the commitment contract.
If no, move to the next step.
Checks the action of every line item other than the first one.
If line item action is of type Change Number, it:
Obtains the parent installed product details through an internal web service call.
Relates the new phone number to the SIM of the parent installed product.
Ends the relationship between the old phone number and the SIM of the parent installed product through an internal web service call.
Creates the history for new phone number through an internal web service call.
Updates the installed product for the product with the new phone number through an internal web service call.
Sets the status of the old phone number to Aging through an internal web service call.
Sets the status of the new phone number to Active through an internal web service call.
If line item action is of type Remove Product, it:
Sets the installed product status to Pending Disconnect through an internal web service call.
Publishes details to the external provisioning system about disconnecting the installed product through an external web service call.
Sets the installed product status to Disconnected through an internal web service call.
If the removed product has a phone number, sets the phone number status to Aging through an internal web service call.
Updates the pricing on the parent installed product through an internal web service call.
If line item action is of type Add Product, it:
Creates an installed product through an internal web service call.
Publishes details to the external provisioning system about the new installed product through an external web service call.
Sets the installed product status to Installed through an internal web service call.
If the added product has a phone number, sets the phone number status to Active through an internal web service call.
For all line items within this order (those that are in any of the mentioned action type and those that are not), the process updates the attributes of their installed products accordingly.
The information is available on the order as well.
The status of the order is changed to Completed, which also takes care of updating all the line statuses to Completed if they are not already in the Completed, Cancelled, or Shipped status.
The Change Service business process ends.
This process is called from the Service Management Activate Service business process. The following graphic illustrates the Prepaid to Postpaid Account Conversion process flow, which performs numerous tasks, such as closing down the prepaid account, moving its installed products to the new postpaid account, notifying the prepaid billing system to transfer any balances (if applicable), and linking the prepaid and postpaid accounts to maintain history:
See Service Management Activate Service Process Flow.
Note. This business process applies to accounts that pay for non-multilevel product bundles only and does not apply to account conversion for multilevel product bundles.
Prepaid to Postpaid Account Conversion process flow initiated from the Service Management Activate Service business process
When this business process is initiated, it:
Calls the RBT_ACCT_LINK (Link Accounts) service operation of the delivered Billing Account web service to establish the link between the old prepaid and new postpaid accounts.
Invokes the Service Management Disconnect Service business process to disconnect the installed products of the prepaid account.
Calls the RBT_ACCT_CONVERT (Complete Account Conversion) service operation of the delivered Billing Account web service to clone any installed products that are carried over from the prepaid account to the postpaid account.
Products that can be moved include the USIM (UMTS Subscriber Identity Module), phone number, and handset.
Calls the RBT_ACCT_UPDT (Update Account) service operation of the delivered Billing Account web service to set the status of the prepaid account to Closed.
Sends a message to the prepaid billing system to transfer and balances on the prepaid account to the postpaid account.
As delivered, the prepaid billing system is simulated by the PrepaidBillingSystemWebService business process. Customers need to replace it with their own integration partner.
The Prepaid to Postpaid Account Conversion business process ends, and returns the control back to the Service Management Activate Service business process.
See Service Management Disconnect Service Process Flow.
This process is initiated from service management orders in which the PAC request action is performed. It validates if a PAC is issued. If a PAC is issued, the installed product is updated with the information. If not, the service management order is updated with a note.
The following graphic illustrates the PAC Request process flow that is used to perform PAC validation:
PAC Request process flow for validating port-in authorization code
When this business process is initiated, it:
Copies payload values into the PAC validation simulator message.
With this data, it calls a third-party web service called MNPThirdPartySimulator (it is a placeholder that customers need to replace with their own web services). The simulator responds with an outcome of true or false.
A reason for denial is provided in the response if the outcomes is false.
If the outcome is true, calls the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered Installed Product web service to update the PAC value and the PAC expiration date.
PAC expiration date = current date + 30 days
If the outcome is false, calls the RO_SERVICEMGT_ADDNOTE service operation to add a note to the service management order stating the reason for denying the PAC request.
The PAC Request business process ends.
This process can be called from service management orders (activate service) or new orders. The following graphic illustrates the Service Management Activate Service process flow, which performs numerous activation tasks, such as updating the phone number, updating the SIM, invoking the Prepaid to Postpaid Account Conversion business process, updating the installed product status, and communicating with both the provisioning and billing systems:
See Prepaid to Postpaid Account Conversion Process Flow.
Service Management Activate Service process flow for updating service information in CRM and external billing and provisioning systems (1 of 2)
Service Management Activate Service process flow for updating service information in CRM and external billing and provisioning systems (2 of 2)
When this business process is initiated, it:
Calls the RO_SERVICEMGT_GETACTSRVCMSG (Get Activate Service Message) service operation of the delivered RO_SERVICEMGT (Service Management) web service to get inputs for the RBTActivateService business process.
If it is a service management order, performs the following activities:
If the phone number is assigned during activation:
First, it calls the RO_NUMMGT_SETNUMBERSTATUS (Set Number Status) service operation of the delivered RO_NUMMGT (Number Management) web service to update the phone number status to Pending Activation.
Then, it calls the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered RF_INST_PRODUCT (Installed Product) web service to update the phone number on the installed products.
Next, it calls the BillingActivateServiceRequest service operation of a third-party web service (BillingSimulator) to notify them about the phone number.
If the SIM is in pending activation:
First, it calls the RO_NUMMGT_SETSIMSTATUS (Set SIM Card Status) service operation of the delivered RO_NUMMGT_SETSIMSTATUS (Number Management) web service to the update SIM status to Activated.
Then, it calls the ProvisioningActivateRequest service operation of the third-party web service (ProvisioningSimulator) to notify them of SIM change. Then, it calls the RO_SERVICEMGT_IMSI_CHG (IMSI change operation) service operation of the delivered RO_SERVICEMGT (Service Management) web service to update SIM on installed products.
Lastly, this service activation business process stops.
If the order is for prepaid to postpaid conversion, performs the following activities:
It calls the RO_SERVICEMGT_GETDISSRVCMSG (Get Disconnect Service Details) service operation of the delivered RO_SERVICEMGT (Service Management) web service to get inputs for the ConvertPreToPostPaid business process.
It calls the delivered RBTConvertPreToPostPaid business process to convert the product from prepaid to postpaid.
Checks if the convergent order synchronization needs to be performed.
Important! This step is applicable only if the current order has sibling orders (from the same parent convergent order) that are dependent on it. For example, in a convergent order where two products with the brings and removes line relationship, the target child order depends on the source child order and a brings and removes installed link cannot be established until the installed products for both child orders are created.
A notification message is sent from the convergent order synchronization process when it's completed. The Service Management Activate Service process moves on to the next step upon the receipt of this notification.
Calls the ProvisioningActivateRequest operation of the third-party web service (ProvisioningSimulator) to publish information about account details and installed products.
Calls the RO_NUMMGT_SETNUMBERSTATUS (Set Number Status) service operation of the delivered RO_NUMMGT (Number Management) web service to set the phone number status to Assigned.
If order is for a prepaid account, calls the AccountBalanceRequest operation of the third-party web service (BillingSimulator) to get the account balance.
If the account balance is greater than zero or it is not a prepaid account, calls the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered RF_INST_PRODUCT (Installed Product) web service to update the installed product status to Activated.
Note. The RF_INST_PROD_UPDATE service operation also updates the status of existing installed links for multilevel installed products. If the installed product is created for a commitment product, this service operation updates the status of the installed commitment, its installed links and its commitment contract to Activated, followed by updating the start and end dates of the commitment contract based on the current date this service activation process runs.
If the account balance is equal to zero and it is a prepaid account, performs the following activities:
Calls the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered RF_INST_PRODUCT (Installed Product) web service to update the installed product status to Pending Top-Up.
Calls the HotlineRequest operation of the third-party web service (HotlineSimulator).
If it is a service management order, calls the RO_ORDER_COMPLETE (Order Completion) service operation of the delivered RO_ORDER (Order) web service to change the order status to Complete.
Important! For multilevel product bundles, the order status change applies to both service management orders and simple orders.
The Service Management Activate Service business process ends.
The Service Management Suspend Service process performs various tasks on service management orders for suspending services, which includes notifying billing and provisioning systems, updating install product statuses, processing lost or stolen handsets, and creating up-sell or cross-sell email and leads, as illustrated in the following graphic:
Service Management Suspend Service process flow for handling service suspension requests
This diagram illustrates the Delayed Email and Lead process flow, which creates an up-sell or cross-sell sales lead targeting the customer with the suspended service and sends an email notification:
Delayed Email and Lead process flow for creating a sales lead and sending an email notification to customer with the suspended service
When this business process is initiated, it performs these high-level tasks in parallel:
Suspends the customer's service.
It updates the high-level installed product or installed service status to Pending Suspension.
This is accomplished using the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered Installed Product web service.
It publishes a message to both the billing (prepaid or postpaid) and provisioning systems notifying them of the service suspension.
This activity contains three stub processes: Prepaid Billing System, Postpaid Billing System, and Provisioning System.
Note. Customers need to replace stub processes with actual web services that interact with their billing and provisioning systems.
It waits for the first response message from either the billing or provisioning system.
It updates the high-level installed product or installed service status to Suspended.
This is accomplished using the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered Installed Product web service.
Processes up-sell or cross-sell lead and email.
This is a conditional activity that is based on the business unit settings and whether or not a replacement handset has already been purchased by the customer.
It initiates the Delayed Email and Lead subbusiness process, which creates a lead and an email in parallel:
Creates lead:
i. Waits x number of days before the process continues (if specified in the business unit settings).
ii. Validates that the service is still in the status of suspended.
This is accomplished using the RF_INST_PROD_GET (Get Installed Product) service operation of the delivered Installed Product web service.
iii. Creates a lead.
This is accomplished using the RSF_LEAD_CREATE (Create Lead) service operation of the delivered Sales web service.
Creates email:
i. Waits y number of days before the process continues (if specified in the business unit settings).
ii. Validates that the service is still in the status of suspended.
This is accomplished using the RF_INST_PROD_GET (Get Installed Product) service operation of the delivered Installed Product web service.
iii. Creates an email correspondence request.
This is accomplished using the delivered CMF_WS_ENABLE web service.
Processes lost or stolen handset.
This is a conditional activity that is based on the customer's reason for suspending the service.
It initiates the Lost or Stolen Handset business process. This process consists of sending a message to the Equipment Identity Registry (EIR) system to blacklist the lost or stolen handset and is documented separately.
After all parallel tasks are completed, the process updates the service management order status to Complete. This is accomplished using the RO_ORDER_COMPLETE (Order Completion) service operation of the delivered Order web service.
The Service Management Suspend Service business process ends.
See Business Object Delivered Web Services, Delivered Web Services, Delivered Web Services and Service Operations.
This process is a combination of the Suspend Service and Change Service business processes. It is invoked from service management orders, supporting all the capabilities provided by each of the two standalone processes. The Suspend Service and Change Service business processes are executed in serial order, as illustrated in the following graphic:
Service Management Suspend and Change Service process flow for executing the Suspend Service process prior to the Change Service process
When this business process is initiated, it performs two high-level tasks in serial:
Suspends the customer's service.
Changes the customer's service.
The Service Management Suspend and Change Service business process ends.
The process performs various tasks on service management orders for resuming services, which includes notifying billing and provisioning systems, updating install product statuses, processing previously lost or stolen handsets, and creating up-sell or cross-sell email and leads, as illustrated in the following graphic:
Service Management Resume Service process flow for handing service resumption requests
This diagram illustrates the Delayed Email and Lead process flow:
Delayed Email and Lead process flow for creating a sales lead and sending an email notification to customer with the request to resume service
When this business process is initiated, it performs these high-level tasks in parallel:
Resumes the customer’s service.
It updates the high-level installed product or installed service status to Pending Resume.
This is accomplished using the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered Installed Product web service.
It publishes a message to both the billing (prepaid or postpaid) and provisioning systems notifying them of the service resumption.
This activity contains three stub processes: Prepaid Billing System, Postpaid Billing System, and Provisioning System.
It waits for the first response message from either the billing or provisioning system.
It updates the high-level installed product or installed service status to Activated.
This is accomplished using the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered Installed Product web service.
Processes up-sell or cross-sell lead and email.
This is a conditional activity that is based on the business unit settings.
It initiates the Lead and Email subbusiness process, which creates a lead and an email in parallel:
Creates lead:
i. Waits x number of days before the process continues (if specified in the business unit settings).
ii. Creates a lead.
This is accomplished using the RSF_LEAD_CREATE (Create Lead) service operation of the delivered Sales web service.
Create Email:
i. Wait Y number of days before the process continues (if specified in the business unit settings).
ii. Create an email correspondence request. This is accomplished using the delivered CMF_WS_ENABLE web service.
Process previously lost or stolen handset.
This is a conditional activity that is based on the customer's reason for resuming the service.
It initiates the Lost or Stolen Handset business process. This process consists of sending a message to the EIR system to whitelist the found handset and is documented separately.
After all parallel tasks are completed, the process updates the service management order status to Complete. This is accomplished using the RO_ORDER_COMPLETE (Order Completion) service operation of the delivered Order web service.
See Also
Referral or Lead-Related Business Process Flow
This process performs various tasks on service management orders for disconnecting services, which include notifying billing and provisioning systems, updating install product statuses, processing lost or stolen handsets, and creating up-sell or cross-sell email and leads, as illustrated in the following graphic:
Disconnect Service process flow for handing request to disconnect services (1 of 2)
Disconnect Service process flow for handing request to disconnect services (2 of 2)
This diagram illustrates the Delayed Email and Lead process flow:
Delayed Email and Lead process flow for creating a sales lead and sending an email notification to customer with the request to disconnect service
When this business process is initiated, it performs these high-level tasks in parallel:
Disconnects the customer's service.
This is accomplished by invoking a business process called Disconnect Installed Product, which performs the following tasks:
Updates the high-level installed product or installed service status to Pending Disconnect.
This is accomplished using the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered Installed Product web service.
Note. For multilevel installed products, the RF_INST_PROD_UPDATE service operation also updates the status of the related installed link.
Sends a notification to the CO synchronization process, which invokes the synchronization process. This step applies if the service management order contains product components that are migrated to a different multilevel contract in another order (which is processed by a different BPEL business process).
The disconnect service process instance is put on hold until it receives a message from the CO synchronization process, confirming that a message has been sent to the provisioning system from the target contract.
Publishes a message to both the billing (prepaid or postpaid) and provisioning systems notifying them of the service disconnection.
This activity contains three stub processes: Prepaid Billing System, Postpaid Billing System, and Provisioning System.
Waits for the first response message from either the billing or provisioning system.
Updates the high-level installed product or installed service status to Disconnected.
This is accomplished using the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered Installed Product web service.
Note. The RF_INST_PROD_UPDATE service operation also updates the status of existing installed links for multilevel installed products. If the installed product is created for a commitment product, this service operation updates the status of the installed commitment, its installed links and its commitment contract to Disconnected.
Sets any disconnected phone numbers that are associated with the service to aging.
This is accomplished using the RO_NUMMGT_SETAGING (Set Number to Aging) service operation of the delivered Number Management web service.
Retires any SIM cards that are associated with the disconnected service.
This is accomplished using the RO_NUMMGT_SETSIMSTATUS (Set SIM Card Status) service operation of the delivered Number Management web service.
Processes up-sell or cross-sell lead and email.
This is a conditional activity that is base on the business unit settings.
It initiates the Delayed Email and Lead subbusiness process, which creates a lead and an email in parallel:
Creates lead:
i. Waits x number of days before the process continues (if specified in the business unit settings).
ii. Creates a lead.
This is accomplished using the RSF_LEAD_CREATE (Create Lead) service operation of the delivered Sales web service.
Creates email:
i. Waits y number of days before the process continues (if specified in the business unit settings).
ii. Creates an email correspondence request.
This is accomplished using the delivered CMF_WS_ENABLE web service.
Processes lost or stolen handset.
This is a conditional activity that is based on the customer's reason for disconnecting the service.
It initiates the Lost or Stolen Handset business process. This process consists of sending a message to the EIR system to blacklist the lost or stolen handset and is documented separately.
After all parallel tasks are completed, the process updates the service management order status to Complete. This is accomplished using the RO_ORDER_COMPLETE (Order Completion) service operation of the delivered Order web service.
The Service Management Disconnect Service business process ends.
See Also
Referral or Lead-Related Business Process Flow
This process handles lost, stolen, or found handsets that are associated with customers' services. A handset is blacklisted if it is lost or stolen. A handset is whitelisted if it is found.
Note. Lost or Stolen Handset is a subbusiness process that is called from these main business processes: Service Management Disconnect Service, Service Management Suspend Service, and Service Management Resume Service business processes.
The following graphic illustrates the Lost or Stolen Handset process flow that blacklists lost or stolen handsets and whitelists found handsets:
Lost or Stolen Handset process flow for handling lost or stolen and found handsets
When this business process is initiated, it:
Verifies the make, model, and serial number of the handset provided.
Blacklists the handset in the Equipment Identity Registry (EIR) registry, if the handset is being reported as lost or stolen and service is being suspended or disconnected.
If the handset is being reported as found and the service is being resumed, the process whitelists the handset in the EIR registry.
Returns control to the calling business process.
The EIR is delivered as a stub web service, which represents a customer's or a third-party EIR service.
This process is initiated from service management orders which contain the Port In action. The process controls the flow of business events involved in porting in a phone number from one wireless carrier to another. This process is only executed after a separate process has successfully validated all customer account, address, phone and billing information, and it is illustrated in the following graphic:
Service Management Port In process flow for handling service requests to port in phone number from another wireless service provider
When this business process is initiated, it:
Copies payload values into a PortIn Date Request message.
With this data, it then calls a stub process (a placeholder for a third-party web service) called PortInDateRequest. This is an asynchronous call. The third-party web service responds with an agreed port-in date.
Processes the response that is received from the third-party system.
If the response indicates that the number porting procedure cannot happen, this process logs the exception message and ends.
If the response returns a port-in date successfully, it calls the RF_INST_PROD_UPDATE (Update Installed Product) service operation of the delivered Installed Product web service to update the port-in date on the installed product.
If the update fails, this process logs a message and ends.
Calls a third-party web service to request the port in completion notification.
This is a stub process (a placeholder for a third-party web service) called PortInCompleteNotification. This is an asynchronous process.
When the Complete Notification response is received, the third-party system has completed its part of the porting process. Remaining porting tasks continue in the CRM system.
If a temporary number is assigned to the port-in, calls the RO_NUMMGT_SETAGING (Set Number to Aging) service operation of the delivered Number Management web service to release this temporary number back to inventory with the standard aging.
Calls the RO_NUMMGT_SETNUMBERSTATUS (Set Number Status) service operation of the delivered Number Management web service to set the port-in number to Active.
Calls the ProvisioningChgRequest service operation from the delivered RBTProvisioningSimulator placeholder to let an external billing system know that the port-in number is now active.
Sets the service management order status to Complete by calling the RO_ORDER_COMPLETE (Order Completion) service operation of the delivered Order web service.
The Service Management Port In business process ends.
This process synchronizes child orders in convergent orders so that any updates to installed links that span across more than one child order can be completed successfully. It is initiated after the submission of a convergent order and that the synchronization among its child orders are deemed necessary. The information of the process instance is passed onto the child orders so they can maintain communications with the process while it is in progress. Process payload contains all the information on child order dependencies and is used to orchestrate child orders of the convergent order.
For orders that are created to handle package migrations, this process is often called to synchronize child orders:
Before installed products involved are set to the Pending status.
Before messages are sent to the provisioning system.
For more information, refer to the Order Fulfillment for Package Migration discussion under the Understanding Package Migration Requests section.
See Understanding Package Migration Requests.
Note. The convergent order synchronization process is called by these business processes: Communication New Order Process, Change Service Process, Service Management Activate Process, and Disconnect Service Process.
Convergent order synchronization process
When this process is initiated, it:
Check if a new account is marked for creation in the convergent order.
If yes, this process triggers the New Account Creation process, which creates the new accounts needed for the order. During this time, all processing for child orders is put on hold until notifications are returned, which confirm the successful creation of the accounts. The New Account Creation process generates all new accounts within the parent synchronization process to enable the same new accounts to be reused across multiple child orders.
See New Account Creation Process Flow.
If no, this process moves on the next step.
Waits on receiving notifications from individual child orders acknowledging that pending installed products have been created successfully for the products on the orders, and updates payload with the information received in the notifications.
Checks if any child orders (with installed products created for them) is ready to be fulfilled or provisioned based on the notifications it receives in the previous step.
If yes, it sends a notification message to each of them individually.
If no, the synchronization process starts over from step 2.
Checks if any further synchronization is needed for the convergent order.
If yes, the synchronization process starts over from step 2.
If no, the synchronization process ends.
This business process is responsible for creating billing accounts. It is a subbusiness process and has to be triggered by another standalone business process, which can be one of these processes:
Convergent Order Synchronization process.
Communications New Order process.
Change Service process.
This diagram illustrates the New Account Creation business process flow:
New Account Creation process flow
Note. At any given instance, a calling process only triggers the New Account Creation process once regardless of the number of new accounts that need to be created.
The New Account Creation process contains two loops, one for performing credit check and the other for creating the actual accounts. Before accounts are created, the process calls for credit validations (to be performed by an external web service) to ensure that the credit values are equal or higher than the predefined threshold value and that it would not get terminated half way due to negative credit check result for some of the order's bill-to customers.
After all the requested accounts are created, the process ends by sending a synchronization notification to the calling process so that the rest of the calling process, which is put on hold during the account creation procedure, can continue.
Checks if the new account to be created is a prepaid or postpaid one.
If it's a prepaid account, no credit check is required. Go to the next step.
If it's a postpaid account, the process calls an external web service to perform credit check. If the credit check does not meet the threshold value that is defined for the business process, the business process is terminated and the web service returns a failure notice to the calling business process.
Checks if any more of bill-to customers or consumers are in line to be processed. This loop continues until all customers with a new account request in the order are processed.
Creates an account in the CRM system through an internal web service call.
This applies to both prepaid and postpaid accounts.
Creates an account in the prepaid or postpaid billing system, depending on whether this is a prepaid or postpaid account.
The account creation is done through an external web service call. After the account is created successfully, the external billing system sends the CRM system a response with the newly created account in the Active status.
If the account is created with a nonactive status, the business process waits for a defined period of time for the account to become active.
At the end, the account information is sent to the CRM system through an internal web service call to update the order as well as the corresponding internal billing account.
This account creation loop continues until all new accounts in the order are generated.
The account creation process ends and it returns the new account notification to the calling business process.
See Communications New Order Process Flow, Change Service Process Flow, Convergent Order Synchronization Process Flow.
This table lists the subbusiness processes and stub business processes that are used in each of the delivered Order Capture business process (an x marks the inclusion of the sub or stub business process in the corresponding main business process):
Use of sub and stub business processes in delivered Order Capture business processes (1 of 3)
Use of sub and stub business processes in delivered Order Capture business processes (2 of 3)
Use of sub and stub business processes in delivered Order Capture business processes (3 of 3)
This section discusses:
The Agreement web service.
The Billing Account web service.
The Order web service.
The Phone Number Administration web service.
The Service Management web service.
The Service Order web service.
See Also
PeopleSoft delivers the Agreement Creation For Order service operation for the Agreement (RO_AGREEMENT) web service. This operation creates agreements for orders. It takes a capture ID and returns a successful status if the agreement is created. The service operation handler takes care of validating the various requirements before the agreement is created. An error message is returned if the operation fails.
This table provides the technical name, operation type, and messages names of the Agreement Creation For Order service operation:
Service Operation |
Operation Type |
Request Message |
Response Message |
Agreement Creation For Order (RO_AGREEMENT_CREATE_FOR_ORDER ) |
Synchronous |
RO_AGREEMENT_CREATE_REQ |
RO_AGREEMENT_CREATE_RES |
PeopleSoft delivers these service operations for the Billing Account (RBT_BILLING_ACCOUNT) web service:
Complete Account Conversion.
This operation takes a prepaid billing account number that needs to be converted to postpaid account and returns a successful status if the account conversion is completed. An error message is returned if the operation fails
Link Accounts.
This operation takes the numbers of two billing accounts (for example, a prepaid account and a postpaid account) to be linked, and returns a successful status if the account linkage is built. An error message is returned if the operation fails.
Update Account.
This operation takes a billing account number and the status to which the account needs to be updated, and returns a successful status if the status update is completed. An error message is returned if the operation fails.
Create Billing Account.
This operation takes a capture ID and returns the number of the billing account that is created for that order.
This table provides the technical names, operation type, and message names of the service operations that are related to the Billing Account web service:
Service Operation |
Operation Type |
Request Message |
Response Message |
Complete Account Conversion (RBT_ACCT_CONVERT) |
Synchronous |
RBT_ACCT_CONVERT_REQ |
RBT_ACCT_CONVERT_RES |
Link Accounts (RBT_ACCT_LINK) |
Synchronous |
RBT_ACCT_LNK_REQ |
RBT_ACCT_LNK_RES |
Update Account (RBT_ACCT_UPDT) |
Synchronous |
RBT_ACCT_UPDT_REQ |
RBT_ACCT_UPDT_RES |
Billing Account Create (RBT_BILLING_ACCOUNT_CREATE) |
Synchronous |
RBT_CREATE_BACCT_REQ |
RBT_CREATE_BACCT_RES |
PeopleSoft delivers these service operations for the Order (RO_ORDER ) web service:
Order Completion.
This operation sets the status of the order to Completed. It also sets the status of all line items in the order to Completed if they are not already in the Completed, Canceled or Shipped. It takes a capture ID and returns a successful status if the order is set to completed. An error message is returned if the operation fails.
Create Installed Product for Order.
This operation creates installed products for orders. It also creates relationships amongst all the created installed products. It takes a capture ID and returns a successful status if the installed product is created. An error message is returned if the operation fails.
Order Shipment Notification.
This operation receives advanced shipping notices (ASNs) for orders from an external fulfillment system. It takes care of updating the line item status of the received shipment to Shipped. It also establishes the relationship between the line item and the line item-SIM records.
Relate Services to SIM.
This operation associates SIMs with installed services. It takes an setID, installed service ID, and ICCID, and returns a successful state if the association is complete. An error message is returned if the operation fails.
This table provides the technical name, operation type, and message names of the service operations that relate to the Order web service:
Service Operation |
Operation Type |
Request Message |
Response Message |
Order Completion (RO_ORDER_COMPLETE) |
Synchronous |
RO_ORDER_COMPLETE_REQ |
RO_ORDER_COMPLETE_RES |
CreateInstalledProductForOrder (RO_ORDER_INSTALLED_PRODUCT_CRT) |
Asynchronous Request/Response |
RO_ORDER_INSTALLED_PRODUCT_REQ Queue: ORDER_QUEUE |
RO_ORDER_INSTALLED_PRODUCT_RES Queue: ORDER_QUEUE |
Order Shipment Notification (RO_ORDER_NOTIFYSHIPMENT) |
Asynchronous - One Way |
RO_ORDER_NOTIFYSHIPMENT_REQ Queue: ORDER_QUEUE |
N/A |
Relate Services to SIM (RO_ORDER_RLT_INST_SVCS_TO_SIM) |
Synchronous |
RO_ORDER_RLT_TO_SIM_REQ |
RO_ORDER_RLT_TO_SIM_RSP |
PeopleSoft delivers these service operations for the Phone Number Administration (RO_NUMMGT) web service:
Add Number History.
This operation generates history details for phone numbers. It takes
inputs such as customer ID, customer's role type ID, contact ID, contact's
role type ID, and phone number, and returns a successful status if the operation
is completed. An error message is returned if the operation fails.
This
operation can be used whenever a phone number is assigned to a customer.
End Number to SIM Relationship.
This operation disassociates phone numbers from their related ICCIDs (Integrated Circuit Card Identifier), which are serial numbers of the SIM cards. It takes a phone number and its related ICCID, and returns a successful status if the operation is completed. An error message is returned if the operation fails.
This operation can be used whenever a phone number is no longer in service or transferred to another SIM or ported out to a different carrier.
Set Number to Aging.
This operation changes the status of a phone number to aging. It takes a phone number and returns a successful status if the operation is completed. An error message is returned if the operation fails.
This operation can be used when a phone number is either disconnected or released by an external carrier.
Set Number Status.
This operation sets the status of a phone number. It takes a phone number and the status to which the phone number needs to be set, and returns a successful status if the status update is completed. An error message is returned if the operation fails.
This operation can be used to set the status of the phone number during the life cycle of a phone number.
Set SIM Card Status.
This operation sets the status of a SIM card. It takes an ICCID and the status to which the ICCID needs to be set, and returns a successful status if the status update is completed. An error message is returned if the operation fails.
This operation can be used to set the status of the SIM card during the life cycle of a SIM.
Relate a Number to a SIM.
This operation assigns phone numbers to SIMs. It takes a phone number and an ICCID, and returns a successful status if the phone number is linked to the ICCID. An error message is returned if the operation fails.
This operation is can be used whenever a phone number is activated on a SIM.
This table provides the technical names, operation type, and message names of the service operations that are related to the Phone Number Administration web service:
Service Operation |
Operation Type |
Request Message |
Response Message |
Create Number History (RO_NUMMGT_CREATE_HISTORY) |
Synchronous |
RO_NUMMGT_HISTORY_REQ |
RO_NUMMGT_HISTORY_RES |
End Number Relationship (RO_NUMMGT_END_SIM_RELATIONSHIP) |
Synchronous |
RO_NUMMGT_END_RELATE_REQ |
RO_NUMMGT_END_RELATE_RES |
Set Number to Aging (RO_NUMMGT_SETAGING) |
Synchronous |
RO_NUMMGT_SETAGING_REQ |
RO_NUMMGT_SETAGING_RES |
Set Number Status (RO_NUMMGT_SETNUMBERSTATUS) |
Synchronous |
RO_NUMMGT_SETNUMSTATUS_REQ |
RO_NUMMGT_SETNUMSTATUS_RES |
Set SIM Card Status (RO_NUMMGT_SETSIMSTATUS) |
Synchronous |
RO_NUMMGT_SETSIMSTATUS_REQ |
RO_NUMMGT_SETSIMSTATUS_RES |
Relates a Number to a SIM (RO_NUMMGT_SIMRELATE) |
Synchronous |
RO_NUMMGT_RELATE_REQ |
RO_NUMMGT_RELATE_RES |
PeopleSoft delivers these service operations for the Service Management (RO_SERVICEMGT) web service:
Add Install Product.
This operation creates installed products for service management, for lines with the Add action code. It takes a capture ID and line number, and returns a successful status if the operation is completed. An error message is returned if the operation fails.
Service Management - Add Note to Order.
This operation adds notes to service management orders. It takes inputs such as the capture ID, notes summary, note details, note type, and the visibility option, and returns a successful status if the note is added. An error message is returned if the operation fails.
Note that this operation may also be used on non-Service Management orders.
Service Management - Add and Submit Order.
This operation adds and submits service management orders. It takes inputs such as the business unit, customer BO ID, install product ID, action, action reason, associated capture ID, start and end dates, and returns the status of the operation, as well as the capture ID and status of the new order if the operation is completed. An error message is returned if the operation fails.
Get Activate Service Message.
This operation gets the inputs for the Service Management Activate Service business process. It takes the capture ID as input and returns the message structure that the Service Management Activate Service business process requires to activate a service.
Get Attribute for an Installed Product.
This operation takes a capture ID and line number and returns the attribute information of the installed product for the corresponding line item.
Get Disconnect Service Details.
This operation gets the inputs for a call to the Prepaid to Postpaid Account Conversion business process. It is called by the Activate Service business process immediately before it calls the Prepaid to Postpaid Account Conversion business process. This operation takes an account ID and returns information about this account that has disconnected its service.
IMSI (International Mobile Subscriber Identity) Change Operation.
This operation is used when the SIM on a service is changed. It sets the installed product status for the old SIM to be Disconnected and the installed product status for the new SIM to be Installed. It moves all child install products from the old SIM to the new SIM and ends the relationship between the old SIM and the phone number. It takes a capture ID and returns a successful status if the operation is completed. An error message is returned if the operation fails.
Remove Installed Product.
This operation removes installed products from service management orders, for lines with the Remove action code. It takes a capture ID and line number and returns a successful status if the operation is completed. An error message is returned if the operation fails.
Update Service Management Order Status.
This operation updates the status of service management orders. It takes a capture ID, a line number, and current status code, and returns a successful status if the operation is completed. An error message is returned if the operation fails.
Modify Multilevel Product Bundle.
This operations performs modifications to multilevel installed products and installed links based on line actions selected in the service order. It may add or remove products and links and perform migrations as needed. It takes a capture ID and in response updates multilevel product hierarchy.
The Get New Service Message service operation is not being used.
This table provides the technical names, operation type, and message names of the service operations that are related to the Service Management web service:
Service Operation |
Operation Type |
Request Message |
Response Message |
Add Install Product by Capture (RO_SERVICEMGT_ADDINSTPROD) |
Synchronous |
RO_WS_SM_DS_REQ |
RO_WS_SM_OUTPUT_DS_RES |
ServiceMgt - Add Note to Order (RO_SERVICEMGT_ADDNOTE) |
Synchronous |
RO_SERVICEMGT_ADDNOTE_REQ |
RO_SERVICEMGT_ADDNOTE_RES |
Service Mgt Add & Submit Order (RO_SERVICEMGT_ADDSUBMIT) |
Synchronous |
RO_SERVICEMGT_ADDSUB_REQ |
RO_SERVICEMGT_ADDSUB_RES |
Get Activate Service Message (RO_SERVICEMGT_GETACTSRVCMSG) |
Synchronous |
RBT_GET_ACTSRVC_MSG_REQ |
RBT_GET_ACTSRVC_MSG_RES |
ROServiceMgtGetAttr (RO_SERVICEMGT_GETATTR) |
Synchronous |
RO_WS_SM_DS_REQ |
RF_INST_PROD_UPDATE_REQ |
Get Disconnect Service Details (RO_SERVICEMGT_GETDISSRVCMSG) |
Synchronous |
RO_SERVICEMGT_CONVERT_DIS_REQ |
RO_SERVICEMGT_CONVERT_DIS_RES |
IMSI change operation (RO_SERVICEMGT_IMSI_CHG) |
Synchronous |
RBT_IMSI_CHG_REQ |
RBT_IMSI_CHG_RES |
Remove Installed Product (RO_SERVICEMGT_RMVINSTPROD) |
Synchronous |
RO_WS_SM_RMV_REQ |
RO_WS_SM_RMV_OUTPUT_DS_RES |
ServiceMgt Update Order Status (RO_SERVICEMGT_UPDSTATUS) |
Synchronous |
RO_SERVICEMGT_UPDSTATUS_REQ |
RO_SERVICEMGT_UPDSTATUS_RES |
MLPBModifyService (RO_SERVICEMGT_MLPB_CRT) |
Asynchronous Request/Response |
RO_MLPB_CH_DS_REQ |
RO_MLPB_CH_DS_RES |
PeopleSoft delivers the Service Order Create service operation for the Service Order (RO_SERVICE_ORDER) web service. This operation creates service orders for the orders. The service operation handler takes care of validating various requirements for the creation of service orders and subsequently creates them. It takes a capture ID and returns a successful status if the status update is completed. An error message is returned if the operation fails.
This table provides the technical name, operation type, and messages names of the service operation that is related to the Service Order web service:
Service Operation |
Operation Type |
Request Message |
Response Message |
Service Order Create (RO_SERVICE_ORDER) |
Asynchronous Request/Response |
RO_SERVICE_ORDER_CREATE_REQ |
RO_SERVICE_ORDER_CREATE_RES |
You can view the elements and fields that are included in each operation message through PeopleTools.
To view a list of field names and aliases for a particular message:
Select PeopleTools, Integration Broker, Integration Setup, Messages.
Enter the name of the message that you want to view in the Message Name field and click Search.
The Message Definition page appears.
Click the message name link under the Parts grid.
The system opens the Message Definition page in a new browser. This step is required only if you selected a container message. If you selected a parts message in step 2 above, proceed directly to step 4.
Note. The system utilizes both container messages and parts messages. A container message may contain one or more parts. The parts message has the actual list of data fields.
Click the plus sign next to the table name at the bottom of the page to view the fields and aliases associated with the message.