Submission on behalf of @gabrielborja
One of our clients presented a particularly interesting challenge in the EDI space.
The challenge:
Our client needed a reliable way to generate numeric, incrementally assigned EDI control numbers that act as unique identities across multiple data flows. Normally, this kind of identity generation would be handled by a dedicated database service, but in this case, the client didn’t have one available.
Our solution:
By creatively leveraging multiple features within Celigo’s platform, we built a fully contained solution no external database needed.
Here’s how we did it:
- Robust connection concurrency control:
We set up a dedicated Celigo connection configured with a concurrency limit of 1. This ensured that all flows requiring control numbers would run sequentially, preventing any risk of duplicate numbers being assigned if two flows tried to generate numbers at the same time. - Celigo’s State API for persistent storage:
We used the State API to store the latest assigned control number for each object type. This allowed the integration flows to retrieve and update the current number safely without conflicts. - Celigo’s APIs for atomic number assignment:
Originally, we implemented this logic using a JavaScript API that read the current number from the State API, incremented it, and updated the stored value in a single step. This atomic operation ensured no duplication. Later, we migrated this process to Celigo’s new visual API builder for easier maintenance and scalability.
The result:
Thanks to this approach, the client now has a robust, scalable numeric identity provider fully managed inside Celigo, without the need for any external database service. This streamlined their EDI workflows and ensured consistent control numbers across all flows.
Flows
In a flow, we have steps to create the EDI control numbers
with the connection set as concurrency 1. This invokes a javascript API that runs the components of this flow to do the number generation as described.
As this was the first version, it only generates 1 number at a time, so the ST/BSR are setup with one to many to generate different ST/BSR numbers for each record.
The new version improves this by allowing a different set of numbers to be created via the request body, for example with this request body:
Allowing one call to generate multiple sequential numbers. These would need to be assigned to each record via a javascript hook, but the advantage of only having one call makes it worth it.
on the visual API builder it looks like this: and the whole process is only calling the Celigo state API twice, first to read the existing numbers, then to update to the latest one.
