The document describes the landscape and high-level transport process for applications in scope of SyWay Release 2. 

Scope 

The transport process for the following applications will be covered in this document.

For each application the following sections will be cover:

• Landscape - Number of instances are in scope for R2.
• Transport Path - Sequence followed when changes are migrated across the landscape.
• Transport Approach: High level approach to migrate changes to each system and transport PIC (person in charge to perform the technical steps to migrate changes).

Out of Scope

As part of Release 2, no changes are expected in the following systems. These are considered as out of scope for this document:

• Ariba Catalog
• Ariba Network
• Keelvar
• SAP Cloud Connector
• SuccessFactors

Detailed technical steps on how transports will be performed is also considered out of scope, as the steps can be found in product documentations.

This document only describes the mechanisms for managing transports (and equivalent methods for moving configuration and code from non-production to production environments). It does not prescribe any specific governance processes such as who performs reviews or approvals of changes, and the scheduling of releases into production. The existing ITGCs will be followed for the applications in scope of Release 2, both during the program's lifecycle and after go-live. In summary, these are: 

• A Change will be used to record and authorise the initial deployment into production of the Release 2 functionality. 
• Following the initial go-live, each transport into production is linked to an authorized Change, and no code will be transported into Prod without it. 
• Emergency Changes may be used to implement time-critical changes following correct authorization. The frequency of Emergency Changes is expected to drop significantly as hypercare progresses, and following the closure of hypercare, should only be used by exception. 
• Standard Changes will be defined and used for routine low-risk deployments, e.g. of authorisation changes. 

Transport Management 

Ariba Sourcing

Landscape

There are 3 Ariba Sourcing tenants for Release 2.

Transport Path

Supplemental Realm will be repurposed for Release 4 after integration test (~Nov 2025). Hence there will be 2 transport paths for Ariba Sourcing:

Transport Approach

The following describes the transport process for Ariba Sourcing:

• For objects that can only be updated by SAP (e.g. custom fields, SAP controlled parameters), separate requests will be raised to SAP to perform the changes for the respective tenants.
• For objects that support export/import (e.g. templates or data), changes will be exported and uploaded to subsequent tenants.
• For all other objects, changes will be manually replicated to subsequent tenants. 

Transport PIC: Ariba functional team

Ariba Cloud Integration Gateway (CIG)

Landscape & Transport Path

Ariba Sourcing and CIG tenants are provisioned together and integrated by SAP. Hence the landscape and transport path for Ariba CIG is the same as Ariba Sourcing. 

Transport Approach

The following describes the transport process for Ariba CIG:

• Since Ariba CIG Supplemental tenant is not linked with Test tenant, changes will be replicated manually. 
• From Ariba CIG Test to Production, Ariba CIG's deployment mechanism will be used to deploy projects from Test to Production.

Transport PIC: Ariba CIG consultant

ICertis Contract Intelligence

Landscape

ICertis landscape consists of 3 tiers.

Transport Path

Configurations and changes will be performed in development and transported to QAS & Production instances.

Transport Approach

Promote Configurations (P2P) Tool will be used to transport changes from non-production systems to Production. 

Transport PIC: ICertis functional team

DocuSign

Landscape

DocuSign landscape consists of 2 tiers. 

Transport Path

Configurations and changes will be performed in non-prod and transported to Production instance during ACO.

Transport Approach

The following describes the transport process for DocuSign:

• Configurations will be replicated manually from non-prod to Production.
• Templates can be exported and uploaded from non-prod to Production.

Transport PIC: R2 Consultant responsible to configure DocuSign

Integration Suite

Landscape

Since the new R2 interfaces deployed in integration suite will be integrating with ECC, Syensqo's Integration Suite will be leveraged and consists of 3 tier landscape. 

Transport Path

Existing transport design will be leveraged for R2: DEV → QAS → PRD.

Transport Approach

Syensqo currently uses BMC Helix and SAP Solution Manager (ChaRM) to manage integration suite transports. For integration suite, the existing urgent change request will be used for R2. 

For more details, please refer to Syensqo Transport Process.

Changes will be transported from DEV to QAS and PRD by Syensqo IT and will be done using a manual approach (export/import and manual configuration in each tenant). 

Transport PIC: Syensqo IT

Syniti

Landscape

There will be one instance for Syniti, which will be used for all project activities.

The following diagram describes how one Syniti instance will be integrated with multiple systems.

• Each ECC client will extract data to its respective source database. 
• 3 separate Syniti jobs will be created corresponding to the 3 Ariba tiers. 
• These Syniti jobs will extract data from the respective source databases depending on the project phase requirements.
• Data will be transferred from Syniti jobs to Ariba tenants via respective interfaces.  

Transport Path

Changes will be made in Development job and tested before similar changes are made in Test job and tested. During cut-over, PRD job will be created. 

Transport Approach

Each Syniti jobs will be configured manually. Hence the data team will need to replicate changes manually.

Transport PIC: Data Team

ECC & PRS

The following sections are applicable for both WP2 and PF2 ECC landscapes. 

Landscape

Syensqo has a 4 tier ECC landscape. 

Transport Path

Syensqo currently uses BMC Helix and SAP Solution Manager (ChaRM) to manage ECC transports. For R2, a normal change request process will be used.

For more details, please refer to Syensqo Transport Process.

Transport Approach

ECC transports are automated by SAP ChaRM. 

Transport PIC: Syensqo IT

Cloud Identity Services

Landscape

Cloud Identity Services (CIS) will be used in R2 landscape to support single sign-on (SSO) and will consist of 3 tier landscape. 

Transport Path & Approach

Configuration will be performed in CIS development, manually replicated to CIS QAS and PRD. 

Transport PIC: Technology Team - Basis

Identity Access Governance (IAG)

Landscape

IAG will be use to automate user ID provisioning for Ariba and ICertis. It will consist of a 2 tier landscape.

Transport Path

Configurations will be performed in non-PRD IAG tenant and transported to PRD tenant during ACO.

Transport PIC: Technology Team - Security

Transport Approach

IAG does not have a automatic transport option. An export/import approach will be adopted to transport cockpit destinations, rulesets and business rules. Other configurations will be replicated manually across tenants.