Asynchronous Bulk API support

[former_member184739]

Hi Expert,

Do we asynchronous bulk API support in SAP GATEWAY to perform bulk data loads especially during integration scenarios.

Regards

Prabaharan

[Former Member]

Hi Prabaharan

My personal view is that Gateway is not suitable framework for this.

Gateway is primarily intended for data consumption. Modifications and inserts through this channel are relatively small compared to the outward flow.

There are many other means of  provisioning data into a system. If you look at HANA, with all of it's modernity, it's still preferential (and heavily supported) to import data from flat files in batch processing. HANA has XSData but that is not the primary means of provisioning into HANA as far as I am aware; as with Gateway, it is intended for consumption.

So you might want to steer away from Gateway for this particular use case to save some pain!

Regards

Ron.

[Former Member]

That is not a bulk update scenario. it's a logical unit of work related to a transaction. A proper bulk update would span more than one transaction worth of data.

If it is order creation, the order insert normally runs as an asynchronous process in backend. Gateway can therefore 'stay on the line' long enough to get back the order ID during the synchronous operation. The actual database update continues asynchronously. To access the concrete state object you may have to wait a bit, but since you have the key, you can query it to confirm backend persistence a reasonable number of times before deciding it's not present.

This is exactly how all current order applications work and they are managed sessions tied to backend driven UIs. Gateway does not work on this principle so expecting it to do so is not reasonable. Setting up callbacks etc is really overcooking things.

Regards

Ron.

[former_member184739]

Hi Ron,

Many thanks for your insights. Your insights are always helpful and make us understand concepts with clarity.

Regards

Prabaharan

[AshwinDutt]

Hello Prabaharan,

You mean to say you would like to establish an asynchronous communication between GW and ECC correct ? This is what i understood from the question. Correct me if i am wrongly understood the question.

I do not think typical asynchronous communication can be supported by GW 2.0

I see Its always been synchronous communication through GW Odata.

This is what i think. It may be correct or may not be as well

May be we can consider Subscription & Notification in GW as a kind of example for asynchronous

communication where we subscribe once and it is notified user when something is changed in back-end.

Regards,

Ashwin

[former_member184739]

Hi Ashwin,

Yes .A typical usecase is to make SAP ECC & GW communicate asynchronously. Whenever an order is created in ECC ,I want to trigger gateway .

Thanks for your inputs.

Regards

Prabaharan

[AshwinDutt]

Hello Prabaharan,

In that case i feel you can make use of Subscription and Notification only.

If at all you decide to implement can have a look the below once ->

Subscription and Notification Flow - SAP NetWeaver Gateway Foundation (SAP_GWFND) - SAP Library

Regards,

Ashwin

[kammaje_cis]

Hi Prabaharan,

My Two Cents,

This seems to be an ideal use case of SAP PI. Did you explore that?

Lets see how it would look using Gateway.

In ECC you create a Sales Order. On the save of the order, you can use the create/change events and in the handler FM, write code to consume an REST/OData service.

regards

Krishna

[former_member184739]

Hi Krishna & Ron,

Thanks for your thoughts and time.

This seems to be an ideal use case of SAP PI. Did you explore that?

Yes exactly but there are few concerns in it. No service builder tool like we have in SAP GW. No JSON support until in PI.

Lets see how it would look using Gateway.

In ECC you create a Sales Order. On the save of the order, you can use the create/change events and in the handler FM, write code to consume an REST/OData service.

1.Yes I am aware of this and we have implemented this. This would be ideal when creating a single Order/Customer in transaction. But when we want bulk data create/change i am afraid if this will work. Thats where i am looking for bulk data API handling. For instance "SalesForce" uses bulk API's which is REST based to do the same. Also recently added OData support too.

http://diginomica.com/2014/11/13/salesforce-adds-native-real-time-integration-lightning-connect/#.VG...

Isn't it cool to have SAP Gateway with both asynshronous communucation/Bulk REST API offerings along with other features ? Correct me why its technically not possible ?

I may sound weird by comparing two independent vendors but the bottom line is i wanted  to open a new door to innovation if its possible.

Regards

Prabaharan

[kammaje_cis]

So when you talk about Bulk APIs and Json, BATCH comes into mind. You might be already aware aware of it. Can it satisfy your requirement?

About Asynchronous behavior at the client end, this can be achieved with calling the service consumption logic in a new session/job. Or you can even call CALL FUNCTION in a NEW TASK.

[former_member184739]

Yes . Will try that krishna .

Regards

Prabaharan

[Former Member]

Just a reminder on any async triggering in the backend. If used properly, POST implies a server side creation and key assignment. Without some kind of synchronous return, the key of the created entity becomes decoupled. The backend should establish the key of the object being created and return that.

The template to follow:

• Client POSTs to GW.
• GW interprets request and passes to BEP.
• BEP CreateEntity assigns a persistence key. This does not take long.
• BEP CreateEntity launches an async process based on the payload.
• BEP returns the original payload with the new key. It is assumed that the creation will be successful.
• Client receives the new entity ID. What happens next depends on the use case, but it might be a confirmation page to the user "Your order number is 123456".
• The client now accesses the resource by GET of this key when retrieving it. In most cases, it will probably have been created in the few seconds that the user is navigating in the client app.

This is an established and proven method for creating orders and other documents, there are no real grounds for getting into complex asynchronous solutions.

One other thing, the async channel should be aimed at execution in an UPD process to avoid resource hogging. DIA processes could run short and cause problems if you simply run a new session. UPD will be queued and is more scalable.

Cheers

Ron

[Former Member]

Hi Prabaharan,

I think the pragmatic answer is that as part of the product features, this would be in the backlog somewhere but not a priority. Given GW's alignment with UI5, something like asynchronous processing would be pointless in the backend if it wasn't supported in the UI.

We looked at this scenario with a client last year and it was not going to be possible with UI5; however since then, there is or will be async support in UI5.

So, watch this space?

Regards

Ron.

[former_member184739]

Hi Ron ,

Will do some learning and analysis on your thoughts and get back to you.

Regards

Prabaharan

[former_member184739]

Hi SAP experts ,

Could anybody throw some lights here?

Regards

Prabaharan