Skip to Content
avatar image
Former Member

TU&C/C scenario questions

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 😉

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • Best Answer
    avatar image
    Former Member
    Jan 23, 2009 at 05:20 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      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.

  • Jan 23, 2009 at 09:31 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • 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

  • avatar image
    Former Member
    Jan 23, 2009 at 09:19 AM

    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.

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Jan 24, 2009 at 08:11 AM

    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?

    Add comment
    10|10000 characters needed characters exceeded