Update Customer’s Custom Name
The CRM / Ordering system updates a Customer in the OCS.io via the RESTful API. The request body contains updated Customer details like External ID, Custom Name, etc. The OCS.io updates the instance of the Customer, then returns Business Transaction containing updated Customer as a payload of the response. Other systems may be notified about the Business Transaction via the Streaming Platform.
|
Attribute Custom Name is not versioned in the OCS.io. The new value comes effective immediately. |
Basic Flow
| Step | Actor | Action | Description |
|---|---|---|---|
1. |
CRM / Ordering |
Call updateCustomerCustomName API |
CRM / Ordering system calls Update Customer’s Custom Name 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 updateCustomerCustomName 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. |
Request Validations
The following validations are performed when updating a customer’s custom name:
-
Customer must be provided in the request, it must be already created in the system and must not be in Deactivated State.
-
Custom Name must be provided in the request.