Update Subscriber State
The CRM / Ordering system updates a Subscriber State in the OCS.io via the RESTful API. The request body contains updated Subscriber State details like State, State Reason, State Valid From. State could be changed with effective date or scheduled to the future with Pending. The OCS.io updates the State of the Subscriber, then returns Business Transaction containing updated Subscriber’s State as a payload of the response. Other systems may be notified about the Business Transaction via the Streaming Platform.
Basic Flow
| Step | Actor | Action | Description |
|---|---|---|---|
1. |
CRM / Ordering |
Call updateSubscriberState API |
CRM / Ordering system calls xref:integration-guide:casm/subscriber/ API exposed by OCS.io. |
2. |
OCS.io |
Request Validations |
OCS.io validates Request whether all mandatory attributes are populated, all data types are valid, ENUMs match with definition, etc. Additionally, OCS.io validates Request against Business Logic. This typically includes, that referenced entity exists in the system, entity has proper state, etc. |
3. |
OCS.io |
Perform Business Logic |
OCS.io performs Business Logic implemented for the Use-Case. |
4. |
OCS.io |
Publish Business Transaction |
OCS.io publishes zero to many messages to Streaming Platform that impacted entities have been changed. |
5. |
OCS.io |
Return updateSubscriberState Response |
OCS.io returns Response to the CRM / Ordering System. |
6. |
DWH |
Subscribe for Business Transactions |
DWH subscribes for Business Transactions to be delivered by Streaming Platform. |
7. |
DWH |
Process Business Transactions |
DWH process Business Transactions internally. This typically includes storing of changed entities, update indexes, update metrics, etc. |
|
Sub-ordinates entities like Offer Subscriptions, etc. are not affected automatically by the State change. It is responsibility of the CRM / Ordering system to change all sub-ordinates entity’s states. |
Request Validations
The following validations are performed when updating a subscriber’s state:
-
Subscriber must be provided in the request, it must be already created in the system and must not be in Deactivated State.
-
State Reason must be provided in the request, it must be configured in the system for given State.
Perform Business Logic
-
If in the Request is State marked with Pending flag, system performs following:
-
System independently whether Pending state is already set on the Subscriber, sets Pending as follows:
-
State = State provided in the Request
-
State Reason - State Reason provided in the Request
-
State Valid From - Date/Time provided in the Request or Request’s Date/Time when State Valid From is not provided
-
-
-
System records change of the State to the Subscriber State History.
-
If Pending is required, system schedules automatic Commit / Rollback in Pending State Schedule.
-
System updates Subscriber’s State.