Question

Odata vs persistent.....best practice?

2

Hi everybody, what are your thoughts regarding best practices using (sap) odata services? Although realtime connections calling odata services to fetch lists, entities, create, update etc are fine, I sometimes struggle with the idea to do everything realtime. So I was thinking what the best (practical) practice currently is. Some thoughts: fetching data from the backend which does not regularly change could be done using a call and store the results in the mendix db using mappings?. Keeping some kind of tag to keep track of the last time things where fetched or even using a subscription and receiving updates when they happen in the backend are possible. Is that an idea? Creating things is something else i think. Maybe it is an idea to fetch the latest and greatest just before I present the user with the option to create something new? Or should you store this as well and temporarily synchronize this with the backend? Hope you have some ideas, especially ideas which are tested in the field :-) Cheers and all the best! Laurens

asked 2019-02-27

Laurens Steffers

2 answers

0

Well, I gave it some more thought. I think I'll do the following:

- When entities are successfully committed to the database I'll call the relevant odata service to create this specific entity (and get some SAP number in return). When it is a change, will call the change of course.

- When lists are requested I'll call the odata service for retrieval and update the mendix db accordingly. Will show the newly fetched data,

- When details are requested, could do the same thing regarding odata retrieval, but most of it is already done using the list retrieval.

- I could try to subscribe to the relevant SAP service to receive data when specific entities in SAP are new/updated/changed.

What do you think?

All the best!

Laurens

answered 2019-03-21

Laurens Steffers

Jacob Boer · Accepted Answer · 2019-03-01

Hi Laurens,

These are valid questions, unfortunately there is no single answer. I like the way you are thinking on the subject.

It's all depending on your requirements. If you do not run into response time issues I wouldn't bother too much. Otherwise here are some of my thoughts on your question.

In cases where it's no problem to not present the latest state of an entity you could think of periodically synching your app with SAP, e.g. the customers-organizational details do not change a lot, having them available at signin maybe makes the signin a tiny bit faster.

But then suppose you want to always start with the list of a customers open orders...How many open orders does a customre typically have...Only a few: no problem to get them from your oData service….A lot: hmmm maybe things start to slow down. But then how to solve this….

If you do not want to persist anything in your app You could load a summary or top 10 synchronously and in background load the rest of this customers data..
If you are able to persist a replica of the data in your app, you could do scheduled daily synchs using the odata services and fetch only the objects that were changed since the last synch..
If you want to go more “state of the art” you could think about a publish/subscribe mechanism, where your SAP system “publishes” updates and your app ‘consumes’ them, thus synching a replica of some of the SAP data. This is a pattern that's becoming more common as part of Microservice Architectures. I'm afraid oData services will not help you in this scenario.