Subscriber Context Retrieval

When Fulfillment Provisioning Catalog is provisioning an order, and has executed all applicable rules, there is a resulting set of technical product orders to be provisioned. Before rule execution, Fulfillment Provisioning Catalog checks if the service order contains the ID of a subscriber context (the subscriber context ID, or scId). If so, Fulfillment Provisioning Catalog invokes custom code to look up the context using this ID.

For details of the subscriber context and associated types, refer to the component documentation.

Note:

Refer to the Fulfillment Provisioning Developer's Guide for details on how to access the component documentation

The subscriber context contains a list of TechnicalProducts and/or Products that the customer already has, each with its corresponding dataset, as well as its own dataset. If there are any Products, Fulfillment Provisioning Catalog will disassemble then and store the resulting TechnicalProducts in the subscriber context.

The subscriber context has its own lifecycle independent of the service order. In simple terms this lifecycle is as follows:

  1. A custom pre-enrichment module defines the scId.

  2. A custom context retrieval module creates the service context for the scId, and populates it using data from external information systems.

  3. Fulfillment Provisioning Catalog uses this information to produce a minimal list of product order flows.

  4. Following provisioning, a custom responder module updates the external information systems to reflect the changes made, and then destroys (or commits) the subscriber context.

Note:

Custom code is required to submit the subscriber context to an external source.

See the section called Implementing subscriber context modules for more details about implementing these custom modules.