WebAS SOAP Runtime - Transaction Commit Issue

[Former Member]

We're calling RFC's via the Web AS SOAP Runtime, and it works perfectly when calling "atomic" RFC's that only require a single RFC call. There are a few RFC's (such as creating a maintenance notification) that need to be followed with a BAPI_TRANSACTION_COMMIT. Unfortunately, these two RFC's need to be called within a single "Transaction"/session.

With Business Connector, there is a way to maintain state and do commit/rollback functionality using cookies between each call and a URL call to do the commit or rollback. With Web AS, there does not appear to be any similar functionality (e.g. two or more SOAP calls wrapped in the same "transaction", with a commit or rollback).

Is there any solution using Web AS (without writing an ABAP wrapper for the two RFC's and remote enabling the new RFC?).

Many thanks!

[thomas_jung]

It appears that this forum topic is very closely related (or exactly the same) to the following. For future searches, it will be useful to reference both:

[Former Member]

I've run this scenario by some people and this is the advice they provided. What you should do is expose BAPI_TRANSACTION_COMMIT and BAPI_TRANSACTION_ROLLBACK using the WS Creation Wizard. You do this by choosing the appropriate function group as the endpoint and manually adding these with "other functions" when creating the VI. Set the Web service communication to "stateful" which will use HTTP cookies.

You can find documentation on the WS Creation Wizard here http://help.sap.com/saphelp_nw04/helpdata/en/e9/ae1b9a5d2cef4ea4b579f19d902871/frameset.htm

Hope that helps.

[Former Member]

Thanks for the input Marc. I'm still unclear as to how this allows us to wrap multiple RFC calls in a single "stateful" session. As an example, we want to be able to call BAPI_ALM_NOTIF_CREATE, which needs to be followed (within a single session) by BAPI_TRANSACTION_COMMIT. With Business Connector, there are URL's that we send to start a session (a cookie is returned which is then passed with the subsequent BAPI/RFC calls), followed by a URL to commit or rollback, and one to clean up/terminate the session.

We're trying to determine what the "analog" to this in WebAS would be.

- Rick

[Former Member]

I've not done this myself, but my understanding is that by enabling the web service to be stateful the cookie you need will automaticlly be sent. By adding COMMIT and ROLLBACK to the VI they will be exposed for web service calls so there is not a seperate url that you would need to be passed back, just invoke these methods while passing in the cookie sent to you in the first call.

[Former Member]

We will experiment with this. However, there does not appear to be a way to propagate an SAP user identity (such as an SSO2 Ticket) through web services exposed using the Web Services Toolkit. In particular, we will be (indirectly) consuming these web services, which are simply calling standard BAPIs, on behalf of a specific user, preferably using the SSO/logon ticket issued by the portal or another ticket provider.

[martijndeboer]

Web Services on WebAS 6.40 support authentication using SAP logon tickets ("SSO2 ticket"). When using this functionality, you can propagate the identity of a user between ws client and web service.

When using an ABAP proxy, you need to create an SM59 destination of type "G" (HTTP connection to ext. server) and check "send SAP logon ticket". When using this destination in the logical port (transaction lpconfig) of the proxy, the identity of the user is propagated.

When using a J2EE proxy, you need to take a deployable proxy and select "Use SAP Logon Ticket" in the IDE (or configure it through the "Web Service Security Service" in the Visual Administrator).

[Former Member]

Thanks, Martijn. We've had success with SSO2 Tickets and authentication. The only remaining problem we have is the inability to commit a BAPI method called via WebAS's SOAP Runtime (no way to call BAPI_TRANSACTION_COMMIT in the same "session" as the initial BAPI call). Needless to say, this severely restricts the utility of the SOAP Runtime.

[thomas_jung]

You might find this weblog interesting.

/people/thomas.jung3/blog/2005/02/14/webservices-a-real-world-implementation-experience

Part of the reason we build our webservices the way we did was because of this very problem you describe. You can see how building wrappers around the BAPIs did end up paying off - with additional flexibility we ended up needing.

[Former Member]

Also an important note: This application is not using JCO or the .NET connector. It is an application that is issuing the appropriate HTTP calls directly. We cannot find any documentation on the HTTP (wire level) syntax and format for the Web AS/ABAP session protocol.