Detailed Phased approach for BW/4HANA In-place conversion across landscapes

[norman]

We have a few general questions about the Phased approach option for the BW/4HANA In-place conversion across the system landscapes. We are confused about the attached image that shows a four phased approach where you would Convert the Development System, Transport and test scenario in Test, and then Transport and Go-live with Scenario in Production. So, our confusion is when we Transport our Phase 1 to Production and our Process chains run that evening in prod, will the converted objects load data from the new ODP data-sources, and the non-converted objects load data from the old SAPI data-sources.

Additionally, can we assume that during Phase 1, when we start the conversion of objects in the (STC01) Conversion Task List and we run into issues, we will fix and collect those objects into a Transport request and continue until the conversion is complete.

Then, we will Transport those requests from Dev to QA, and we will again convert those same objects using (STC01) in QA. 

Thanks, 

Norm

[Vishal_JS]

When migrating a data flow with in-place conversion, we have a situation.

In Development the TRFN of a converted data flow is different from the one converted in Quality system. In such situations, we will not be able to transport any future corrections for the transformations from Dev to QA. Did anyone observe this and resolved the same?

[EduardS]

Hi,

Independent of the Conversion functionality, the TRFN-ID is always generated within the system and is dependent on the system, source and target information. That is the reason why TRFN can have different ID.

See SAP 2774555 - Technical names of Transformations

Transporting will be possible, anyway.

Best Regards,

Eduard

[Vishal_JS]

Hello Eduard,

Thanks for your quick reply and the Note. 

Cheers,

Vishal

[EduardS]

Hello,

As described, you do all application relevant conversion steps (InPlace tasklist runs) in each system (DEV, QAS, PRD). If your scope contains a SAPI DataSource the Transfer Toolbox supports (during tasklist run) the conversion ("switch") from SAPI connection to ODP connection (if all requirements are met in the source systems: SAP Note 2481315).

So, after a tasklist run you might have two source system types pointing at the same physical source system: SAPI and ODP.

If the SAPI DataSource is switched to ODP during the tasklist run, for this DataSource the extraction takes place via the ODP framework. For other, not yet converted SAPI DataSources, the extraction still runs via SAPI.

With regard to the transport procedure.

You can only transport BW object types between systems if they are of the same type. So, an ADSO (former CUBE) can only be transported from DEV to QAS to PRD if the object is already an ADSO in QAS, PRD.

The transport mechanism DOESN'T convert any BW objects (InPlace approach).

Best Regards,

Eduard

[Vishal_JS]

Hello Eduard,

We have converted Classical DSO data flow to a ADSO flow in Dev and QA separately with the conversion tool (In-Place). The Source is a classical DSO and Target is a Infoobject.

What we notice after conversion in both the system is, the TRFN IDs between Infoobject and ADSOs are different in DEV and QA post conversion.

Hence the question, how will future changes could be transported from DEV to QA in future if TRFNIDs are different?

[EduardS]

Hi,

the scenario should preferably be as follows:

1. Convert a scenario (=InfoProvider(s), Dataflow, multiple objects) in DEV. Possible corrections of converted objects are done in DEV and written on a transport request. This transport request can only be transported into the subsequent system if the same objects are converted in the subsequent system.
2. Select and convert exactly the same scenario (=objects) in QAS
3. Select and convert exactly the same scenario (=objects) in PRD

Using this approach leads to the fact that the systems stay in almost the same state and can be maintained through the landscape. Because if an InfoCube is converted in DEV and not yet in QAS, PRD it can't be maintained via transports.

Furthermore, the systems can be switched to the next modes (B4H, R4C) within a reasonable time.

The systems can run in B4H as long as you wish; this mode has no restrictions. In R4C mode no loads are possible.

The technical conversion of the systems will be quite subsequential.

Best Regards,

Eduard

[norman]

Hi Eduard,

[norman]

Hi All, Thanks for your replies, The reason I mention process chains is that we used the "Start BW/4 Transfer Tool" icon in each process chain to create our conversion Task List in STC01. We have multiple process chains for Master data Atrribute by Functonal area, then multiple MD Text loads by Functonal area and finally multiple Transaction Data. Therefore, when we complete each SAP_BW4_TRANSFER_INPLACE conversion, we are completing each process chain. Therefore, when we complete a Scenario in Development and QA, which would be a number of process chains, and then Go-live in Production, would we have a number of Process Chains from the 1st Scenario running with ODP and the other process chains still running with SAPI? Additionally, while we are completing each Scenario, do we remain in Compatibility mode throughout, because you need to complete all the scenarios before we have completed Step "3 - During Transfer Tool" in the B4HANA Readiness Check (RSB4HCONV) tool?

[EduardS]

Hi, starting the conversion tasklist via the process chain modeler is one way to start. But, a process chain is a collector on its own. It will collect all dependent objects, so also objects might be collected although you don't want to collect in that run. Normally, I recommend to use the "scissors" approach. Start with the virtual objects, e. g. MultiProviders. After this, continue with the source system dependent objects, e. g. datasources. After these steps you work BW internal. It is important to divide the objects in packages with no overlaps. Several teams can work on these packages cross systems.

[Vishal_JS]

When migrating a data flow with in-place conversion, we have a situation. In Development the TRFN of a converted data flow is different from the one converted in Quality system. In such situations, we will not be able to transport any future corrections for the transformations from Dev to QA. Did anyone observe this and resolved the same?

[john_hawk]

Hi Norm,

Your attached images didn't come through, but I'll try to answer your questions:

In general for in place conversion the sequence would be Convert Dev -> Fix or replace unconverted objects in Dev -> Convert QA -> Import post conversion fixes from Dev -> Convert Prod -> import post conversion transports.  I would NOT assume process chains would be converted and "ready to run". 

Hope this provides some clarity,

John Hawk