Skip to Content
T A

Add/update object with B1i with custom businesslogic in Transaction notification

Hello all,

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Nov 04, 2013 at 07:20 AM

    *UPDATE* Response form SAP support:

    Note: 1927075 (not released at the moment)

    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


    Symptom


    If you have code in SBO_SP_TransactionNotification that is supposed to block transactions please note that you have to consider the transaction handling mechanism of SAP Business One SDK's DI API to u nderstand the impact on add-ons and scenario steps inintegration framework:


    When using the DI API transaction handling mechanism by calling the functions StartTransaction + EndTransaction of the Company object note that the SBO_SP_TransactionNotification is only called when c alling EndTransaction - while you might expect that it would still be called after each DI API service or object call (that changes data).


    Since integration framework uses this mechanism too to include the DI API calls in its implementation of a 2PC protocol integration frameworkcannot detect any error raised by SBO_SP_TransactionNotific ation at an earlier stage.




    Solution


    The developer of a scenario step is responsible for implementing the required checks in the scenario step - or find other ways.


    The option to implement the required checks in the scenario step requires to run SQL calls - via "B1 Object" call -> Method "B1 Recordset" - or through other checks; calls via the "Call SQL" atom migh t lead to incorrect results since they are not done inside the DI API context.


    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    I'm afraid there's no other solution then check the business logic before add the object. :-(

    Maybe someone has an other option?

    Thanks.

    Kind Regards Teun

    Add comment
    10|10000 characters needed characters exceeded

    • Check note: 1927075

      Symptom

      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.


      Solution

      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.