Update Customer State
The CRM / Ordering system updates a Customer State in the OCS.io via the RESTful API. The request body contains updated Customer 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 Customer, then returns Business Transaction containing updated Customer’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 updateCustomerState API |
CRM / Ordering system calls xref:integration-guide:casm/customer/ 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 updateCustomerState 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 Account, Subscribers, 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 customer’s state:
-
Customer 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 Customer, 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 Customer State History.
-
If Pending is required, system schedules automatic Commit / Rollback in Pending State Schedule.
-
System updates Customer’s State.