SAP Gateway for transactional interfaces?

[Former Member]

Hi All, I was going through this post  -

Post says -

SAP NetWeaver Gateway is not designed to be a channel for the type of transactional applications used by Power Users, neither is it designed to replace existing middleware like SAP NetWeaver PI. In addition to this, SAP NetWeaver Gateway applications are not designed to target A2A or B2B scenarios. Instead, SAP NetWeaver Gateway is the door through which the mass consumption of SAP business data and functionality is made possible. The target audience for SAP NetWeaver Gateway applications is a group known as Occasional Platform Users (OPU). These are people who need ad hoc access to SAP data and functionality in an easy-to-consume manner.

Why Gateway cannot be used for transactional type of interface developments? Is there architecture constraints  that we should be aware of ?

Ranjeet Singh

[former_member184867 · Accepted solution]

The major difference between classical transactional apps and Gateway Apps(Fiori Transactional   apps) is Session handling. Gateway is OData based which is build on REST principles. There is no session handling possibility in Apps based on Gateway.

Classical transactional apps based on WebDynpro or module pool  are heavily dependent on user session. For example: when a user open a PO in edit mode a lock is created in the backed and when the user closes the UI the lock is released. This is not the case gateway as there is no similar locking concept.

Gateway offers Etag handling for  optimistic locking but still is not a direct equivalent of locking concept in the classical  transaction app. Also S/4 apps are utilizing the draft concepts for complex apps.

[former_member230601 · Accepted solution]

Hi Atanu,

Thanks for the details.

1. Could you please suggest more on the Draft concept in S/4 HANA apps ?

2. Also for achieving concurrency control one of the Fiori application is using locks at table level and clear the expired locks by a background process.

Excerpt from the Note '2110680 - Background process to clean up session state'

"The standard SAP locking mechanism uses the enqueue server. The lifetime of an enqueue lock is bound to
the ABAP user session in which it was created - with other words: the ABAP user session is the "owner" of
the lock. If an ABAP user session ends, all locks owned by this ABAP user session will be deleted.
The Fiori applications use OData services for backend communication. For each OData HTTP request a new
ABAP user session is created and terminated directly after the response is serialized, or if an error has
occurred. This means, that at the end of each request all enqueue locks are gone. As of today it is not
possible to set an enqueue lock which survives the end of a standard OData HTTP call.
Therefore locks are stored in a database table and outdated locks must be deleted periodically by a
background process.
Solution
Define a background job for event SAP_SYSTEM_START starting report FDC_START_TIMERDAEMON.
No parameter and variant are required.
The report will start a background process (daemon ) as an asynchronous RFC - visible in SM04 with title
"FDC: Timer Daemon" in transaction SM04. Every 5 minutes the daemon will clean up sessions, that were
not updated the last 120 minutes.
Additionally schedule the background job e.g. every hour, to check, that the daemon is still running."

Also i found one interesting reference in Fiori for implementing locks.

https://experience.sap.com/fiori-design-web/concept/locking/

Could you please suggest your thoughts here ?

Regards

Santhosh Kumar

[former_member184867 · Accepted solution]

As you have already explored a bit on Fiori architecture, you may have understood that locking as per the classical approach is no easy task in this Fiori world.

Sometime one may think of force fitting (or for Specific reasons) session based locking  in Fiori apps . In such cases ,unlocking may need to be introduced by  external agents. One option could be to run some kind of unlocker report periodically. This note speaks about something very similar. May be for specific reasons some Fiori App in finance area required locking and this note explains how to unlock the resources blocked by such apps. However this is not a generic concept that you may like to  embrace for your application.

https://experience.sap.com/fiori-design-web/concept/locking/#! This fiori Design guideline introduces the UI pattern if your app would like to handle Locking scenarios.

Being truly stateless , Gateway does not come with pessimistic locking option.So using Only Gateway on top of your business logic in the Fiori app does not help you much in this direction. (However you can think of optimistic locking as a mechanism for collision control )

In S/4 application we have the concept of Draft pattern, which is something in between. This is enabled using the BOPF framework.

Using draft concept, you actually capture the intermediate states of business objects in the backend. This is like an intermediate stage before actually saving the data. That means every single change made by the user is captured in draft tables. On final submission, the draft data is validated against business logic and  saved in DB.

Using draft approach , Fiori apps can achieve collaboration, locking and usability features.

[former_member230601 · Accepted solution]

Hi Atanu,

Thank you for the details provided.

Using draft approach , Fiori apps can achieve collaboration, locking and usability features.

For custom UI5 applications NOT using S/4 HANA:

Do we have create OData services consuming BOPF objects and inturn BOPF framework will handle the locking(draft approach) implicitly ? Please suggest if there are any example implementation in the existing SAP NW releases to understand the methodology.

Appreciate your help.

Regards

Santhosh Kumar