Re: B1if - _!!Recovery(com_sap_b1i_system_xc)

Hi Szymon,

In addition to Bastian's suggestion..

Each B1i transaction has the lifecycle STARTED → INCOMMIT → COMPLETED or STARTED

→ INROLLBACK → CANCELLED (if error occurs during start phase, then everything is rolled back; otherwise all the calls must be committed). In-doubt (STARTED/INCOMMIT/INROLLBACK) transactions is typically due to unexpected external system behavior or incorrect external data (e.g. connection to B1 is lost during incommit phase, DI does not give response after the call). B1i recovery mechanism will be triggered to redo or undo the transaction in order to come to the final status (COMPLETED/CANCELLED).

To find the in-doubt transactions from integration framework UI:

integration framework → Tools → Control Center → Monitoring → TID-Panel →
Choose [Execution Status] as "STARTED", "INCOMMIT", "INROLLBACK" respectively →
Click [Submit!].

RecoveryPrep is triggered on each time you restart B1i service and every day at 6:00,18:00 to check in-doubt transactions. If there is, RecoveryDo will get triggered to 1) deactivate the original IPO-Step; 2) perform adapter redo/undo directly; 3) If successful performed, IPO-step will get reactivated again; otherwise the IPO-Step will stay deactivated with the reason "Recovery" and !!Recovery stays in queue monitor.

To find the configuration for Recovery mechanism (however it is not suggested to change the configuration):

Integration framework → Tools → Control Center → Configuration → Deployment Panel → Click [Cfg] button for 'xcellerator.xml'  → Click [Cfg] for 'RecoveryStart' and 'RecoveryPrep'.

If you find the IPO PRC_B1.ipo/proc is deactivated by recovery:

• This IPO runs your scenario step if the step runs on the sender side. Does your step contain DI call? If yes, please check out the DI single transaction mechanism documented in the attachment of note 1993784. With the feature switched on, the DI call will only be performed in transaction start phase and cannot be rolled back once it is successfully performed. So design the step appropriately based on business needs.
  

• You can find the hint for the root cause by checking the cancelled transaction for the deactivated IPO steps or the error handling IPO for this IPO Step. Copy the IPO-Step name and paste it to TID-Panel (see below), click [Submit!] to get the list of all cancelled transactions. Click [IPO-Log] to view the exception. If you have debugging switched on, click [ExecDetails] → Click 'Dump of Atom Inbound-Message' to view inbound and outbound debugging log.
  

Let me know if it needs to be explained further for transaction handling.

Regards, qiaoli