Direct APIs, webhooks, data warehouse or client cloud: how each option works with SAP S/4HANA and ECC, and what it asks of your IT team.
In its default setup, GenLots connects to SAP S/4HANA or ECC through two standard APIs, from its own cloud, and fetches the data once or several times a day. This takes about 5 days of IT work on the client side, then 3 days for each additional site on the same SAP instance.
GenLots, an ETH Zurich spin-off and SAP partner, reads from SAP the requirements calculated by MRP (transaction MD04), the material master data and the orders already placed. It writes back optimized purchase requisitions, which replace the proposals MRP would have created. The rest of the process (supplier orders, goods receipt, logistics) stays as it is.
Before starting a project, a client’s IT team therefore asks two questions: how data flows between SAP and GenLots, and how much work this means for them. The answer comes down to four independent choices, made one after the other: which path the data takes, what triggers the exchanges, what data GenLots keeps, and where GenLots runs. This article goes through them in that order, then recommends a combination.
How does data flow between SAP and GenLots?
By default, GenLots integrates with SAP by calling its standard APIs directly. Two other paths exist: the client’s integration platform, or its data warehouse. Each one answers a security or timing constraint, at the cost of more effort on one side or the other.
The direct SAP API is the reference path. On S/4HANA, GenLots reads MRP requirements through the standard API_MRP_MATERIALS_SRV_01 and writes purchase requisitions through API_PURCHASEREQ_PROCESS_SRV. The client opens these two APIs, creates a technical user and allows network access.
The client’s integration platform, such as SAP BTP Integration Suite or MuleSoft, is used when IT policy forbids any direct access to SAP from outside. For GenLots, the calls stay the same. The effort moves to the client, who builds and maintains the flows in their own tool.
Reading from the client’s data warehouse, for example Snowflake, only requires read access from the client. The effort falls on GenLots, which must rebuild the MD04 view in SQL from the replicated tables, differently for each client. The data is no fresher than the copy, often daily, and purchase requisitions are still written back through the API.
| Option | GenLots effort | Client effort | Right choice when |
|---|---|---|---|
| Standard SAP API, direct (reference) | Low, the connector exists (reads MRP requirements, writes purchase requisitions) | Low, about 5 IT days: open two APIs, create a technical user, open network access | By default, on S/4HANA or ECC |
| Client’s integration platform (BTP, MuleSoft…) | Low, the calls are the same | Medium to high: the client builds and maintains the flows in their tool | IT policy forbids any direct access to SAP from outside |
| Reading from the client’s data warehouse (Snowflake…), writing through the API | High: the MD04 view must be rebuilt in SQL, differently for each client | Low: read access | Proof of concept or interim solution. The data is no fresher than the copy, often daily |
Once the path is chosen, the next decision is what triggers the exchanges.
What triggers the exchanges between SAP and GenLots: a schedule or an event?
By default, GenLots fetches data from SAP on a schedule, once or several times a day. The client can also have SAP send a message whenever a requirement changes: this is the event-driven mode, more responsive but much heavier on the client side. The two can be combined in a hybrid mode.
The scheduled mode asks almost nothing of the client. A daily run is enough in most cases, since SAP’s own MRP usually runs once a night and GenLots plans over the supplier lead time plus about a year. Its limit is timing: a change made at 10 a.m. is only picked up at the next run, and the whole scope is recalculated each time.
The event-driven mode relies on a webhook. A webhook is an address at GenLots that the client’s system calls automatically as soon as an event occurs, instead of GenLots coming to ask. GenLots receives the messages, queues them and groups successive changes to the same material before recalculating.
On the client side, SAP must send a message for every change in requirements. On S/4HANA, SAP publishes these change events through SAP Event Mesh, a messaging service that runs on SAP BTP. Without BTP, the alternative is custom development in SAP that calls the GenLots webhook directly, and its effort depends on the client’s SAP version and on its rules for custom code.
We recommend that SAP sends every change within the GenLots scope and that GenLots decides whether to recalculate, since coding this filter in SAP would add even more effort for the client.
The hybrid mode combines both: events during the day, and a full run at night that catches any lost messages. It is useful when requirements change several times a day and must be taken into account the same day.
| Option | GenLots effort | Client effort | Limit |
|---|---|---|---|
| Scheduled: GenLots fetches the data once or several times a day | Low, this is the default mode | Low | A change made at 10 a.m. is only picked up at the next run, and the whole scope is recalculated each time |
| Event-driven: SAP sends a message as soon as a requirement changes (webhook) | Medium: receive the messages, queue them, group successive changes to the same material | High: on S/4HANA, events go through SAP Event Mesh on BTP; without BTP, custom development in SAP, whose effort depends on the SAP version | For clients with a mature IT organization |
| Hybrid: events during the day, full run at night | Sum of both | Sum of both | Useful when requirements change several times a day and must be taken into account the same day. The night run catches lost messages |
Whatever the trigger, GenLots receives the client’s data. The next choice is what it keeps from one calculation to the next.
What data does GenLots keep between two calculations?
By default, GenLots keeps the history of the data behind each calculation: requirements and forecasts, master data and parameters. SAP does not keep this history, because each new forecast and each MRP run replace the previous figures. A stateless mode, in which GenLots keeps nothing between two calculations, is available for clients whose security rules demand it, but it gives up this history.
This history sets GenLots apart, and many clients value it for two uses. The first is the Time Machine, which shows for any past order exactly what GenLots saw when it proposed it: the forecast, the master data and the parameters of the day. When a stockout or an overstock occurs months later, planners can tell a wrong forecast from a wrong parameter.
The second use is forecasting. With the successive versions of each forecast on record, GenLots can see how forecasts drift from one version to the next, and build its own forecasting models from them.
In stateless mode, GenLots keeps no copy of the client’s data between two calculations: each exchange contains everything needed to recalculate the material. Less data stored at GenLots makes a strong security argument, but the Time Machine and the forecast history are lost.
Even in stateless mode, GenLots keeps a record of its own writes. SAP firms any purchase requisition changed through the API, which means MRP no longer touches it at its next run, so GenLots must know which of its requisitions are firmed.
| Option | GenLots effort | Client effort | Right choice when |
|---|---|---|---|
| History kept (default) | Low, this is the default mode | Low: covered by the security review of the SaaS setup | By default. Required for the Time Machine and the forecast history |
| Stateless: nothing kept between two calculations | Medium: each calculation starts from scratch, and the features based on history are switched off | Low in scheduled mode, higher in event-driven mode, where each message must carry all the data for the material | Security rules forbid storing client data outside the company, and the client accepts losing the history |
If security rules go further and forbid any data from leaving the company, the last choice comes into play: where GenLots runs.
Where does GenLots run: in its own cloud or in the client’s?
By default, GenLots runs in its own cloud, as SaaS. Hosting in the client’s cloud remains possible as a fallback, when security rules forbid any data from leaving the company, but it is costly for both parties.
With SaaS, the client’s effort is limited to a security review, since the data leaves the company network. In the client’s cloud, GenLots handles installation, updates and support on infrastructure it does not control. The client, for its part, provides and runs that infrastructure.
| Option | GenLots effort | Client effort | Right choice when |
|---|---|---|---|
| In the GenLots cloud (SaaS) | Low | Low to medium: security review, since the data leaves the network | By default |
| In the client’s cloud | High: installation, updates and support on infrastructure we do not control | High | As a fallback, if security forbids any data from leaving the company |
Which GenLots integration setup should you choose?
To get started, the recommended setup is the direct SAP API, the scheduled mode, history kept and SaaS. It requires the least effort on both sides, about 5 IT days for the client on one SAP instance and 3 days for each additional site. It also starts building the planning history from the very first run.
The other options each answer a specific constraint. The integration platform answers an IT policy that forbids direct access to SAP, and the data warehouse serves a proof of concept or bridges the wait until the APIs are opened. The stateless mode answers security rules that forbid storing client data, at the cost of the history, and the client’s cloud answers rules that forbid any data from leaving the company.
A daily run is enough for most clients, even across several sites. If requirements change several times a day and must be taken into account the same day, the hybrid mode can be added later: the API connector stays in place for the night run and for writing purchase requisitions, so events are added without undoing anything.
Frequently asked questions
How long does it take to connect GenLots to SAP?
Allow about 5 days of IT work on the client side for one SAP instance, using the standard APIs, then 3 days for each additional site on the same instance. On the business side, a key-user planner usually spends 1 to 5 days on validation and testing.
Does GenLots work with SAP ECC?
Yes. GenLots supports both SAP S/4HANA and SAP ECC.
Does GenLots require SAP BTP?
No. The reference path calls the SAP APIs directly, without BTP. BTP only comes in if the client requires its integration platform, or for the event-driven mode, where S/4HANA publishes change events through SAP Event Mesh on BTP unless the client builds a custom development instead.
Does GenLots store the client’s SAP data?
Yes, by default. GenLots keeps the history of requirements, forecasts, master data and parameters behind each calculation, which SAP does not keep. Clients whose security rules forbid it can choose the stateless mode, at the cost of this history.
What is the GenLots Time Machine?
The Time Machine shows, for any past order, the forecast, master data and parameters GenLots used when it proposed that order. It helps planners find the root cause of a stockout or an overstock after the fact. It relies on the history GenLots keeps, so it is not available in stateless mode.
What happens to the proposals SAP’s MRP has already created?
They must not stay next to GenLots requisitions, otherwise a planner could convert one of them into a purchase order and order twice. The simplest way is to switch MRP off for the materials GenLots manages (MRP type ND), so that MRP creates no proposals for them at all.
If the client prefers to keep MRP running, GenLots deletes MRP’s proposals, purchase requisitions and planned orders alike, when it writes its own. In both cases, GenLots can write firmed as well as unfirmed requisitions: the client keeps full control when they become purchase orders.
Do planners have to change tools?
No. GenLots purchase requisitions appear in SAP in place of the MRP proposals, and planners keep their usual transactions. A GenLots interface is available as an option.
