Question on working with tRFC or qRFC with windows client app

[Former Member]

I have the following requirement: "Create a document and classify a document and update state".

I startet with the following BAPIs:

• RfcSessionManager.BeginContext(this.Destination);
• CVAPI_DOC_CREATE
• BAPI_TRANSACTION_COMMIT
• RfcSessionManager.EndContext(this.Destination);

          => Document is created

• RfcSessionManager.BeginContext(this.Destination);
• BAPI_OBJCL_CREATE
• BAPI_TRANSACTION_COMMIT
• RfcSessionManager.EndContext(this.Destination);

          => Document is classified

• RfcSessionManager.EndContext(this.Destination);
• CVAPI_DOC_CHANGE
• BAPI_TRANSACTION_COMMIT
• RfcSessionManager.EndContext(this.Destination);

          => Document status is changed

This works generally but I now wanted to make it more transaction-save (i.e. if the classification cannot be performed (because of wrong parameters entered by the user), the creation of the document should be rolled back also.

In this scenario, I analysed the return messages of the specific BAPIs which returned "E" and informed the user.

So I added the three BAPIs to a transaction like this:

RfcTransaction transaction = new RfcTransaction("testQueue");

RfcTID tid = transaction.Tid;

transaction.AddFunction(CVAPI_DOC_CREATE);

transaction.AddFunction(BAPI_OBJCL_CREATE);

transaction.AddFunction(CVAPI_DOC_CHANGE);

transaction.Commit(this.Destination);

The commit doesn't fail (no exception) but also not classification is created. The document is in the desired state so it seems that the 1st and 3rd BAPI were successfully executed.

I then tried to provoke an error in the 3rd call (updating to unknown status) which obivously led to complete rollback: no document was created but the commit still didn't fail.

UPDATE: Didn't check correctly

The commit doesn't fail (no exception) but the document stays in the first state so it seems only the first BAPI is commited and the following ones are ignored.

UPDATE2:

If I add a BAPI_TRANSACTION_COMMIT after each BAPI-CALL, the document is in the desired state but no classification created:

RfcTransaction transaction = new RfcTransaction("testQueue");

RfcTID tid = transaction.Tid;

transaction.AddFunction(CVAPI_DOC_CREATE);

transaction.AddFunction(BAPI_TRANSACTION_COMMIT);

transaction.AddFunction(BAPI_OBJCL_CREATE);

transaction.AddFunction(BAPI_TRANSACTION_COMMIT);

transaction.AddFunction(CVAPI_DOC_CHANGE);

transaction.AddFunction(BAPI_TRANSACTION_COMMIT);

transaction.Commit(this.Destination);

Is there a way to get information on client side (via NCO) if the operation was really successful i.e. the complete transaction was processed without error?

If there are errors (ie return = "E") how can the messages be retrieved in such a case?

Any help would be greatly appreciated!

Message was edited by: Tobias Buhl

[hynek_petrak · Accepted solution]

Hi Tobias,

what if you implement following sequence:

• RfcSessionManager.BeginContext(this.Destination);
• Call CVAPI_DOC_CREATE
• Check the return e.g. psx_message, on error call BAPI_TRANSACTION_ROLLBACK
• Call BAPI_OBJCL_CREATE
• Check the return table, on error call BAPI_TRANSACTION_ROLLBACK
• 
  
• Call CVAPI_DOC_CHANGE
• Check the return e.g. psx_message, on error call BAPI_TRANSACTION_ROLLBACK
• If all good sofar call BAPI_TRANSACTION_COMMIT
• RfcSessionManager.EndContext(this.Destination);

The guys are discussing the principle on another set of BAPIs : Calling Multiple BAPIs in a single LUW | SCN

Hynek

[MarkusTolksdorf · Accepted solution]

Hi Tobias,

this is what I wanted to recommend as well. Using tRFC only makes sense, if the BAPIs you are using can be used in a transactional context. But even then you would not need a queue, because all of them are executed in the order you add them to the transaction. If you omit the queue, the normal behavior is that the function modules are executed immediately and you should get a notfication  whether the excution was successful or not. The function Commit is actually sending the recorded function modules to the partner system so that they can be executed in the transactional context.

BTW, recording a BAPI_TRANSACTION_COMMIT does not make sense for tRFC. Commits are issued automatically by the tRFC runtime.

Best regards,

Markus

[Former Member · Accepted solution]

Hi Hynek,

unfortunately your proposal doesn't work (already tried it before) because the BAPI_OBJCL_CREATE required that the CVAPI_DOC_CREATE was commited otherwise it reported error that it cannot find the object to be classified...

I have now a workaround to use BAPI_DOCUMENT_CREATE2 which can be filled with the classification so I only need to call this one and CV_API_DOC_CHANGE to change the status. Obviously this works in a transactional manner that can be commited or rolledback in case of error....

[hynek_petrak · Accepted solution]

That's it. Sometimes there are such situations. You can figure out, whether you are happily married only when you marry :-).

[Former Member · Accepted solution]

Hi Markus,

I already thought that BAPI_TRANSACTION_COMMIT wasn't necessary with tRFC.

If I understand correctly, the tRFC transaction-commit only fails if there was an exception during the BAPI-execution but not when there are errors which are recorded in the return structures, correct?

So it can only guaranty that the BAPIs are all given to the backend for execution but not to implement a sequence which depends on the actual result, correct again?

I can live with the workaround described in my update to Hyneks answer but still wonder in which situations the tRFC / qRFCs are really useful...

[Former Member · Accepted solution]

Another question in this context: Is it possible to access the actual return messages of BAPI executed in a tRFC transaction, otherwise after transaction commit, how do I know if the BAPI-chain was successful or not?

[MarkusTolksdorf · Accepted solution]

Hi Tobias,

tRFC does not allow to get return parameters. you can only send data in this case, but not receive some. If an error is listed in the BAPIRETURN, this won't work as expected. This is what I meant with designed for transactional asynchronous context.

Best regards,

Markus

[MarkusTolksdorf · Accepted solution]

Hi Tobias,

this is an important side note: If the prerequisite exists that CVAPI_DOC_CREATE was committed before BAPI_OBJ_CREATE can be called, you cannot call them in a single transaction sequence. Then, using a different approach like you mentioned now, is the best choice.

Best regards,

Markus