Add/update object with B1i with custom businesslogic in Transaction notification
I would like to add (for example) a salesorder with B1i.
This is not a problem, except when the object has some additional checks/business logic (no updates) in the Transaction Notification Stored procedure.
It's the purpose of the Transaction Notification for add some additional checks, but it seems this is not working with B1i.
With the use of the Transaction Notification you can create a single point of validation for a businessobject which is always checked, for GUI, API, DTW etc.
The customer use this business logic for validation some fields: for example (NumAtCard is mandatory).
In B1i we receive a errormessage due the customized check and according errormessage, when we debug the flow. The output of the B1i-flow has an error ("Error during the processing flow - no validation result available").
The atom which adding the businessobject returns the status true. It seems after the flow the rollback (due the custom validation) is executed.
Same behaviour when set option : "Stop processing if fails" in atom to true.
I'd like to receive an error in the correct atom when the custom businesslogic is not valid, just the way the DI-API is working. Then I could do some additional actions.
As a workarround I could check the custom businesslogic between the add and rollback but this is not wanted behaviour, because the whole flow is rolled back.
Somebody an other option?
Thanks for your reply.
Kind Regards Teun
Teun Aben replied
Check note: 1927075
If you have added code to the SBO_SP_TransactionNotification stored procedure that blocks transactions, consider how the transaction handling mechanism of the SAP Business One SDK DI API works using the SBO_SP_TransactionNotification. This can have an impact on Add-Ons and scenario steps in the integration framework.
If you use the DI API transaction handling mechanism calling the StartTransaction() and EndTransaction() functions of the Company object, the transaction handling mechanism only calls the SBO_SP_TransactionNotification stored procedure when calling the EndTransaction() function.
Unlike for the SAP Business One client or for a single DI API call, the transaction handling mechanism does not call the SBO_SP_TransactionNotification stored procedure after each DI API service or object call, when using the StartTransaction() function.
To include DI API calls into the implementation of the two-phase commit protocol, the integration framework uses the DI API transaction handling mechanism. The two-phase commit protocol is an important paradigm of the integration framework architecture. The integration framework cannot detect any error after single DI API service or object calls, because the transaction handling mechanism only calls the SBO_SP_TransactionNotification stored procedure when calling the EndTransaction() function. The integration framework calls the EndTransaction() as soon as it has called all atoms of the flow and processing has not stopped due to other errors.
Until further notice, you must implement checks in your scenario package.
You have the following options:
- Implement checks in the scenario step. You can use the B1 Object call atom with the B1 Recordset method. Do not use the Call SQL atom, because it uses a different database connection and not the one for the DI API.
- Use the SAP Business One outbound channel. If you use the SAP Business One outbound channel in your scenario step, the integration framework puts the message into the Error Inbox. In the Error Inbox, you can delete the message, or try to resend it, if the issue no longer exists in SAP Business One. Even though the integration framework uses the DI API transaction handling in this case, it should be acceptable. The EndTransaction() call is immediately after the SAP Business One object call.
- In the process flow, use a Call Web service atom for the DI API call, if the result of the SBO_SP_TransactionNotification stored procedure is relevant. This opens and closes a transaction within the Web service call, and the synchronous Web service call return the exception in the response.
If you plan to use the Web service mechanism, it is a prerequisite that you do not use a DI object, DI service or DI function call in the scenario step, before you call the Web service. Such a DI call calls the StartTransaction() function, and the DI call in the Web service call also calls the StartTransaction() function. This can temporarily block the transaction.
Consider additionally, whether it is acceptable for the business process that you implement that the B1 object call in the Web service call is persisted in the database. It is not possible to roll it back, after the Web service call has been completed.
We plan to improve the situation for developers in future versions, but currently we cannot provide any changes.