Functional Workflow

The high-level intended workflow of the ActiveControl / SmartShift is described in below diagram.

In summary:
● Development will be done in the ECC source system as per the existing customer process. This will likely include at minimum a ECC Development Test Queue where unit testing is performed, and depending on the customer’s exact workflow, possibly also an outbox where the Transport is automatically released by ActiveControl.
● On ECC outbox approval, the ECC transport will flow through the rest of the ECC workflow. It will also be distributed to the parallel ActiveControl smartShift workflow, which comprises a Merge target and a SmartRetrofit target in series.
● All transports will initially stop in the Inbox of the AC Merge target for Conflict Analysis (ie regardless if it is an ABAP Repository of Configuration/ABAP Dictionary object)
● It is expected that the ECC transport will already be released by the time it reaches the AC Merge Inbox. Check Transport Release (0014) analyser can be used to ensure this.

(1) In the Merge Inbox, ALL transports (ie both ABAP Repository of Configuration/ABAP Dictionary objects) will stop for Approval. Conflict Analysis will run at this point, highlighting if any changes made to the same object in the target S/4 Development system. Mark as Manually Applied will be used as normal when not wanting to Merge. The Transport Form will be approved if desired to be Merged.
(2) In the Merge Import Queue, import will create a Merge request in the target S/4 Development system. This is as per the standard Merge process within ActiveControl.
(3) In the smartRetrofit Inbox, all ABAP repository/source code objects will stop for Approval. Conflict Analysis will run at this point, highlighting if any changes made to the same object in the target S/4 Development system. Mark as Manually Applied can be used as normal when not wanting to Merge. The Transport Form will be approved automatically by the polling report.
(4) In the smartRetrofit Import Queue, the ActiveControl/SmartShift integration will run. This is described in more detail in the following section.
(5) In the smartRetrofit Outbox, the ActiveControl/SmartShift integration will run, and an automated approval will be done when the process is complete. Again, this is described in more detail in the following section.

Notes
(i) The Merge/smartRetrofit does not need to be done directly after Development. It can also be done after Production if preferred.
(ii) The SmartRetrofit polling target must have Inbox/Import/Outbox.