23 Mar 2021

Online Lunch Meetup 10

Speakers

Marc Couturier

Customer Success Director at MuleSoft

Koen Certyn

Solution Architect B2B/CX at AB Inbev

Joseph Abi-Khalil

Digital transformation Manager at AB Inbev

Join our next API meetup hosted by MuleSoft to learn more about API Led Design & how AB Inbev implemented it in their API Journey.

Agenda:

▶ 11h55: Opening Webinar Room
▶ 12h00: Start

▶ API Led Connectivity: Accelerating Integration Success
by Marc Couturier – Customer Success Director at MuleSoft
+Q&A

▶ From IPA to API: API led design @ AB Inbev
by Koen Certyn – Solution Architect B2B/CX at AB Inbev
& Joseph Abi-Khalil – Digital transformation Manager at AB Inbev
+ Q&A

▶ 13h00: Closing

Have a question that wasn’t answered during the talk? Get your anwers!

I want an answer to my question

Q&A

How do you solve the typical 1+N problem where 1 call to the Simulate API triggers N calls to prices, N calls to Stock check , N calls to ... ? How do make this performant?

So the calls are handled 1by1. Meaning 1 call to simulate will trigger 1 call to price DD etc. We also introduced parallel handling of those calls to avoid queuing those messages and decreasing the response time.

How are the internal APIs connecting to SAP? SAP PI/PO?

We mainly use Mulesoft

Can you share your experience with locking, doing reservations on stock, making sure if the simulation doesn’t end in an order, all reservations are cleared in the non transactional world of API orchestrations?

Here maybe 1 thing to clarify we only reserve the products on actual creation of order not on simulation. During simulation, we share with our customers that for that requested date a requested quantity is available (or not) however if no order is placed, if the customer simulates 1 day later, results might of course be different.

How did you react towards customers that were reluctant to adopt the API?

Sometimes for technical reasons, customers couldn’t adopt the API. Hence stayed with current way of working for ordering. However, we do from time to time checkpoints with them to see if the situation evolved on their side & if they are ready to call our API.

To what degree did such a transition move your systems away from code-first to configuration-based APIs? Are you maintaining much less code in this way?

Due to real specific purposes of the APIs, default connectors/processes were used to retrieve/post data to the systems in our landscape (Salesforce/SAP/..). Relative limited coding is needed on the lower levels of the APIs. In the higher tier APIs, the main coding goes to the orchestrating/triggering/transforming the requests.

16725 Comments. Leave new