on 11-18-2015 9:35 AM
I have the following requirement: "Create a document and classify a document and update state".
I startet with the following BAPIs:
=> Document is created
=> Document is classified
=> 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
Hi Tobias,
what if you implement following sequence:
The guys are discussing the principle on another set of BAPIs : Calling Multiple BAPIs in a single LUW | SCN
Hynek
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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....
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...
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
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.