TU&C/C scenario questions

[Former Member]

Hi all,

what exactly is the part of PI 7.1 in a TU&C/C scenario besides handling WS-RM?

- Is it PI that is taking care of the "simulated" LUW as called here in this paper? [https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/00ffdb4d-e869-2a10-7688-891d7eea1b12]

- Is PI also taking care of the compensate message that is registered at first and sent in case of a system crash?

- If so, what needs to be done on the provider side? Just create the business logic for the tentative updates or also handling the LUW (open, commit, rollback)?

- What are the prerequisites for the provider system. Does it have to be NW in a particular version or is it also possible for NonSAP?

Thanks a lot for all your help,

be sure to get points

[Former Member · Accepted solution]

One more question at sreenivas. Where did you set the flag for TU? In the table? And how did you implement the rollback

Could you maybe send me a code sample, still don't get my arms around the whole implementation on provider side!

Thanks a lot so far.

[Former Member · Accepted solution]

Hello,

Actually, we need to use transaction id created at consumer side and pass the same to provider in all three operations(TU, confirm and compensate) .. you can refer this code from help.sap.com

As i didnt find any real time scenario to use transaction id, i have added one more field to the table for the flag. and updated depending on the operation.

Regards,

Sreenivas.

[Former Member]

OK, so you created the logic for the rollback and commit scenario (flag within table that indicates a tentative update) by your own. That was the information I have been looking for. Thanks for all your help!!!

But what do you mean with "real time" scenario. From my point of view you need the transaction id on every scenario, how could you determine which LUW you have to rollback or commit otherwise?

[prateek]

Is it PI that is taking care of the "simulated" LUW as called here in this paper?

I guess it is handled by the provider system

Is PI also taking care of the compensate message that is registered at first and sent in case of a system crash?

Compensate call is registered at the consumer.

If so, what needs to be done on the provider side? Just create the business logic for the tentative updates or also handling the LUW (open, commit, rollback)?

Provider does not actually handles the LUW, it just simulates the LUW usage.

What are the prerequisites for the provider system. Does it have to be NW in a particular version or is it also possible for NonSAP?

Applicable to ABAP 7.0 SP 14+ systems or ABAP 7.1 systems

Regards,

Prateek

[Former Member]

Thanks for your quick and valuable answers so far.

So does this mean that in the provider system I just have to implement the necessary business logic for the tentative update interfaces? Due to the fact that a regular synchronous call to a abap system that implements such a interface with a function module call - to let's say create a PO - will immediately hand it over to the database, how can this be rolled back when a compensate message is sent?

The bottom line of the questiona is actually: what is meant by a "simulated" LUW? Do I have to take this "simulated" LUW into consideration while implementing the interface for the tentative update call or is this handled by PI?

Did any one of you already implement a backend for a TU&C/C scenario. I just found a client implementation here ([http://help.sap.com/saphelp_nwpi71/helpdata/de/46/9722ec79f115eae10000000a114a6b/frameset.htm]) which was very interesting so far.

Thanks a lot,

Mane

[Former Member]

Hello,

I have implemented a scenario using TU&C/C(in ABAP 7.0 > sp14). Scenario is for employ creation.(Its not real time example).

First consumer will register the comensate method which will trigger in case of failures or when ever rollback is called.

Consumer will send a synchronous Tentative update(Creation) to provider, in which i have maintain employ table and set the flag as TU after inserting and sending the response back to the consumer.

If response is success, call confirm method and commit work else roll back.

Comensate method on provider side will update the flag to CONFIRM

Roll back will call comensate method.

Compensate method on provider side will update the flag to COMENSATE.

Regards,

sreenivas.

[prateek]

what is meant by a "simulated" LUW?

That would mean that whole process would appear as if an LUW is maintained at provider but while implementing you don't have to consider this.

Do I have to take this "simulated" LUW into consideration while implementing the interface for the tentative update call or is this handled by PI?

No. Just the operation Compensate and Confirm has to be implemented at provider.

Regards,

Prateek

[Former Member]

Hi,

This pattern has been developed to fill the gap in transactional behavior that currently exists today with synchronous messages. Synchronous messages, by their nature, cannot provide guaranteed delivery in and of themselves in cases of system or communication failure the way asynchronous messages can. Leveraging the guaranteed delivery capabilities of asynchronous messages, the TU&C/C pattern provides a reliable means to make one of more synchronous update calls in a transactional context

Replying to your queries,

1. yes, the entire process will be handled in one LUW and is controlled by consumer.

2. Compensate message is registed in consumer side and will be triggereed in case of system crash, and if we do rollback.

3. Thie is applicable only for ABAP 7.1 systems.

Regards,

Sreenivas.