Base Types
The messages that pass through the provisioning flow are of the type ::prov::ServiceOrder , which is derived from the Streams message, ::OSAStreams::Message.
A Fulfillment Provisioning service order comprises four separate data layers: service order data, product order data, technical product order data, and work order data.
There is also a proxy interface available: prov::ServiceOrderProxy, that you can use to query the status of a service order without affecting its processing. Refer to the interface documentation for the prov package for more details on this feature.
For example, a service order could be a request to activate a Global System for Mobile Communication (GSM) customer account. At the product order level, the activation of a GSM account could include the activation of the products GSM_VOICE, GSM_FAX, and CLIP. At the work order level, the activation of each of these products would involve separate steps, or work orders. The activation of GSM_VOICE alone could include separate work orders for creating an AUC subscriber account, a VMS subscriber account, and an HLR subscriber account as well as for updating the newly created HLR account.
In Fulfillment Provisioning an instance of sodata::ServiceOrderData represents one service order; an instance of sodata::ProductOrderData represents one product order or technical product order; and an instance of sodata::WorkOrderData one work order. As the example indicates, one service order can be related to many product orders, and one technical product order can be related to many work orders.
The following figure shows a UML model of the separate data layers and their relationships.
For a detailed description of the ServiceOrderData, ProductOrderData, and WorkOrderData interfaces, refer to the component documentation for each of these.