Appendix: Order Capture Delivered Business Processes and Web Services

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

Understanding Web Services

Click to jump to parent topicDelivered Business Processes

This section discusses:

Click to jump to top of pageClick to jump to parent topicCommunications New Order Process Flow

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:

  1. 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.

  2. 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.

  3. 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).

  4. 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.

  5. 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.

  6. 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.

  7. Updates the corresponding installed product (that is, the serial ID) for each received shipment notice.

    This is done through an internal web service call.

  8. Updates the corresponding order line status to Shipped for each received shipment notice.

  9. 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.

  10. Performs these activities for each line item in the order if the nature of the product in the line item is Wireless:

    All line-level activities are completed.

  11. Creates service orders for installed products, if applicable, through an internal web service call.

  12. Creates an agreement for the order, if applicable, through an internal web service call.

  13. 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.

  14. 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.

  15. 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.

    See Service Management Activate Service Process Flow.

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.

Click to jump to top of pageClick to jump to parent topicMobile Number Portability Process Flow

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:

  1. 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.

  2. 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:

    1. 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.

      See Business Object Delivered Web Services.

    2. Copies all needed customer details and payload data into the Port Request message.

    3. 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.

    4. Receives a response from the third-party system and checks for the validity of the details.

    5. 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.

    6. 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.

  3. 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.

    See Service Management Port In Process Flow.

  4. Copies the input payload to the output data.

  5. 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.

Click to jump to top of pageClick to jump to parent topicChange Service Process Flow

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. Checks the action of every line item other than the first one.

  6. If line item action is of type Change Number, it:

  7. If line item action is of type Remove Product, it:

  8. If line item action is of type Add Product, it:

  9. 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.

  10. 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.

Click to jump to top of pageClick to jump to parent topicPrepaid to Postpaid Account Conversion Process Flow

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:

  1. 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.

  2. Invokes the Service Management Disconnect Service business process to disconnect the installed products of the prepaid account.

  3. 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.

  4. 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.

  5. 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.

Click to jump to top of pageClick to jump to parent topicPAC Request 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:

  1. 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.

  2. 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

    See Delivered Web Services.

  3. 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.

Click to jump to top of pageClick to jump to parent topicService Management Activate Service Process Flow

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:

The Service Management Activate Service business process ends.

See Delivered Web Services.

Click to jump to top of pageClick to jump to parent topicService Management Suspend Service Process Flow

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:

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.

Click to jump to top of pageClick to jump to parent topicService Management Suspend and Change Service Process Flow

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:

  1. Suspends the customer's service.

    See Service Management Suspend Service Process Flow.

  2. Changes the customer's service.

    See Change Service Process Flow.

The Service Management Suspend and Change Service business process ends.

Click to jump to top of pageClick to jump to parent topicService Management Resume Service Process Flow

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:

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

Delivered Web Services

Delivered Web Services

Click to jump to top of pageClick to jump to parent topicService Management Disconnect Service 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:

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

Delivered Web Services

Click to jump to top of pageClick to jump to parent topicLost or Stolen Handset 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:

  1. Verifies the make, model, and serial number of the handset provided.

  2. 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.

  3. 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.

Click to jump to top of pageClick to jump to parent topicService Management Port In Process Flow

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:

  1. 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.

  2. Processes the response that is received from the third-party system.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

See Delivered Web Services.

Click to jump to top of pageClick to jump to parent topicConvergent Order Synchronization Process Flow

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:

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Click to jump to top of pageClick to jump to parent topicNew Account Creation Process Flow

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:

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.

  1. 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.

  2. 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.

  3. Creates an account in the CRM system through an internal web service call.

    This applies to both prepaid and postpaid accounts.

  4. 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.

Click to jump to top of pageClick to jump to parent topicUse of Sub and Stub Business Processes in Delivered Business Processes

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)

Click to jump to parent topicDelivered Web Services

This section discusses:

See Also

Understanding Web Services

Click to jump to top of pageClick to jump to parent topicAgreement

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

Click to jump to top of pageClick to jump to parent topicBilling Account

PeopleSoft delivers these service operations for the Billing Account (RBT_BILLING_ACCOUNT) web service:

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

Click to jump to top of pageClick to jump to parent topicOrder

PeopleSoft delivers these service operations for the Order (RO_ORDER ) web service:

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

Click to jump to top of pageClick to jump to parent topicPhone Number Administration

PeopleSoft delivers these service operations for the Phone Number Administration (RO_NUMMGT) web service:

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

Click to jump to top of pageClick to jump to parent topicService Management

PeopleSoft delivers these service operations for the Service Management (RO_SERVICEMGT) web service:

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

Click to jump to top of pageClick to jump to parent topicService Order

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

Click to jump to parent topicViewing Message Elements

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:

  1. Select PeopleTools, Integration Broker, Integration Setup, Messages.

  2. Enter the name of the message that you want to view in the Message Name field and click Search.

    The Message Definition page appears.

  3. 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.

  4. 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.