Issue

A key decision must be made on how to deploy the SAP Global Trade Services (GTS) environment. SAP GTS can be deployed in two main ways:

  • Option A: SAP GTS Co-Deployed within S/4HANA – This approach integrates SAP GTS directly within the S/4HANA system, operating in a dedicated client. It eliminates the need for a separate GTS instance, streamlining system management.
  • Option B: Deploying SAP Global Trade Services (GTS) as a standalone system while integrating it with SAP S/4HANA  – SAP GTS runs as an independent instance while integrating with SAP S/4HANA, rather than being co-deployed within it. 

This document analyses the benefits, limitations, and feasibility of each option to identify the best fit for the project’s objectives and long-term strategy.


Recommendation

It is recommended to adopt the Co-Deployed approach within S/4HANA ( Option A ) in a dedicated client . This deployment retains the full functionality of SAP Global Trade Services (GTS), just as in a Stand-alone setup, while offering additional benefits.

Key advantages of the Co-Deployment approach include:

  • Simplified IT landscape – Reduces system complexity and integration efforts.
  • Lower infrastructure costs – Eliminates the need for a separate GTS instance.
  • Optimized operations & maintenance – Unified management within S/4HANA.
  • Enhanced compatibility – Seamless integration with core SAP processes.
  • Future Scalability: If functional or technical requirements change, SAP GTS can be transitioned from a co-deployment to a standalone deployment in the future.

Given these benefits, the Co-Deployed approach within S/4HANA (Option A) is the recommended deployment option to maximize efficiency and minimize operational overhead.


Background & Context

As part of the  SyWay Project, the implementation of SAP Global Trade Services (GTS) is required, along with its integration into the SAP S/4HANA system. There are two SAP GTS deployment approaches available for the project, each with distinct infrastructure and operational requirements.

This document evaluates these options and recommends the most suitable approach based on the project's specific requirements, complexity, and business objectives. The evaluation considers factors such as system compatibility, ease of implementation, costs, and system landscape requirements.

A decision on the deployment approach must be made at this stage, as the SAP GTS Co-Deployed approach within S/4HANA presents an opportunity to optimize landscape costs. The available deployment options are:

Option A: SAP GTS Co-Deployed within S/4HANA

Starting from S/4HANA 2023, SAP GTS can now run in a separate client of a S/4HANA Instance without compromising the functional scope—an improvement over previous S/4HANA versions. Key characteristics of this deployment include:

  • SAP GTS and SAP S/4HANA share the same database and application server, meaning they also share system resources. 
  • GTS runs on a separate client in the S/4HANA platform. This is required because as indicated in the SAP documentation “You must install SAP Global Trade Services, edition for SAP HANA 2023 in a separate client from SAP S/4HANA 2022/2023 or master data distribution from S/4 to GTS will not work”.
  • Unified Maintenance: Updates and patches are managed together with SAP S/4HANA, creating a technical dependency between both solutions.
  • IT Operations and administrative tasks are shared by both solutions.

Option B: Deploying SAP Global Trade Services (GTS) as a standalone system while integrating it with SAP S/4HANA 

This has been the traditional approach for SAP GTS implementations. Until S/4HANA 2023, this was the only deployment option that ensured full functional scope availability.

Key characteristics of this deployment include:

  • Independent System: SAP GTS operates on dedicated application and database servers, separate from S/4HANA.

  • Integration Interfaces Required: Data exchange with S/4HANA relies on RFC, IDocs, APIs, or other integration methods.

  • Separate Administration & Maintenance: System operations, updates, and administration must be managed independently.

  • Higher Infrastructure Costs: Requires additional servers, resources, and licenses, increasing total cost of ownership (TCO).

While this deployment offers full functional scope as for option A, it also results in higher complexity and costs due to separate system management and integration requirements.

More details are available here:


Assumptions

  • No Functional Restrictions: Both deployment options provide the same functional capabilities.
  • Future Flexibility: A co-deployed SAP GTS system can be separated into a standalone deployment if needed.

  • Software Component Alignment: S/4HANA and SAP GTS must remain synchronized in terms of software components, creating a technical dependency in both scenarios.

  • System Time Zone: All SAP applications, including SAP GTS, operate on UTC time, following SAP’s recommended best practice. There are no specific time zone requirements for SAP GTS.

  • No Workbench Object Conflicts: SAP GTS uses its own workbench objects, ensuring no impact when running in a co-deployed mode.

  • Project Implementation Unaffected: Both options fully support all required activities for a SAP GTS Greenfield implementation, including:

    • Interface configuration

    • Data loading

    • Testing

    • Customizing

    • Development

  • No Historical Data Migration: Existing historical data from the current SAP GTS system (SID WGP) will not be migrated. Only open items could be required.

  • Co-Location of GTS with S/4HANA: In order to ensure good performance of the many thousands of run-time checks performed by transactions inside S/4HANA against GTS, the network latency between GTS and S/4HANA must be very low. This necessitates deploying GTS and S/4HANA in the same datacenter location, and precludes the use of a single global GTS system for all S/4HANA systems. 


Constraints

  • Choosing RISE for a standalone SAP GTS system will require a long-term financial commitment, as the system cost will apply for the entire contract duration (7 years). Therefore, a final decision must be made at this stage.
  • Many processes inside S/4HANA require integration with GTS to execute various checks during the execution of processes. This requires a low-latency connection to GTS to avoid impacting performance. The integration also requires a high degree of reliability, because any downtime of GTS or interruption in the network connection could prevent transactions from being executed inside S/4HANA. As a result, the GTS system must be co-located with S/4HANA to achieve the required low latency and reduce the number of failure points in their communication path.


Impacts

  • No Functional Impact: Both the co-deployed and standalone deployment options provide the same SAP GTS functionality.
  • Number of systems: Considering that there will be multiple S/4HANA instances in the landscape (e.g. China, Rest of the World), there will necessarily be multiple GTS systems in order to ensure that run-time checks performed by S/4HANA against GTS are not unduly impacted by network latency between the S/4HANA and GTS systems, or differing maintenance schedules. 
  • Additional interfaces must be built between the two GTS systems in order to reduce the administrative overhead and eliminate dual maintenance of master data. For example, Sanctioned Party Lists, licenses, product classifications, and other master data must be synchronised between the two GTS systems to ensure consistency and eliminate triple maintenance.
  • A single user interface will be needed for users to access all two GTS systems from a single launching point. SAP Work Zone will be used to enable this (see KDD036). 
  • Technical Dependencies: SAP S/4HANA and SAP GTS versions must remain aligned from a software component perspective. As SAP GTS evolves, new functionalities may require patches or upgrades. To mitigate potential impacts, the following actions are recommended:

    • Patch & Upgrade Strategy: Establish a proactive approach to keep systems updated based on technological advancements and business requirements.

    • Regression Testing Strategy: Implement a structured regression testing process, leveraging automated testing tools to minimize effort and ensure system stability. This should be analyzed as part of the Testing Strategy.

  • S/4HANA Resource Requirements: Running SAP GTS within S/4HANA will increase slightly resource demands as per analysis performed.

    • The assumption based in current EWA analyzed is that GTS requirements would be similar to a system Size catalogued as "Small" with 2/4 CPUs, 16/32GB RAM ,<500GB disk size and 60 users.

    • The necessary adjustments to S/4HANA sizing must be analyzed to accommodate these additional workloads. However, this analysis is beyond the scope of this document.


Business Rules

None


Options considered

Option A: SAP GTS Co-Deployed within S/4HANA system

The co-deployed option refers to deploying SAP GTS within the same SAP S/4HANA system rather than operating it as a standalone instance. In this approach, SAP GTS runs on the S/4HANA platform as a separate client. 

Key Points:
  • Shared Infrastructure: SAP GTS and SAP S/4HANA share the same database and application server . Therefore, additional system resource requirements must be analyzed to ensure optimal performance.
  • Resource Analysis  based on the Early Watch Alert (EWA) from 17 March 2025 for the current SAP GTS production environment (SID WGP):
      • WGP runs on a shared AWS r6i.2xlarge server with following attributes: 8 CPUs, 64GB RAM, 1.1TB DB disk.
      • SAP GTS specific tables occupy approximately 346GB.

      • Other technical tables (logs, change documents...) occupy approximately 219GB
      • DB Disk Average monthly growth is 7GB approximately 
      • Current DB disk use is high (950 GB) , but as per the data strategy, historical data migration is not required, only open items will be migrated, significantly reducing disk space requirements.

      • 61 active users.
      • Based on above data we can conclude that estimated additional infrastructure needs on S/4HANA for SAP GTS system are equivalent to a "Small" size system (e.g., 2/4 CPUs, 16/32GB RAM, <500 gb disk, 60 users).

  • Separate Client: GTS operates in a dedicated S/4HANA client, ensuring functional separation. That also mean that the workbench objects are shared between all the SAP S/4HANA system clients. This will not have any impact since SAP GTS Standard objects use its own Namespace (/SAPSLL/) and packages (/SAPSLL/*). Custom objects (if required) for GTS should be created in the a dedicated namespace to avoid conflicts with other potential developments.

  • Simplified Maintenance: Updates, patches, and operations are managed together with SAP S/4HANA, reducing administrative effort.

  • Real-Time Access: Direct access to S/4HANA data improves efficiency.

  • Cost Efficiency: Eliminates the need for an external SAP GTS system, leading to lower infrastructure and operational costs.

  • System Resources Considerations: Since SAP GTS and S/4HANA share infrastructure resources, proper sizing adjustments must be factored in during implementation.

  • The co-deployed client applies to every S/4HANA instance to be created in Syensqo landscape, that means:
    • a co-deployed GTS client in the primary S/4HANA instance in the EU, and
    • a co-deployed GTS client in the S/4HANA instance for China

Option B: Deploying SAP Global Trade Services (GTS) as a standalone system while integrating it with SAP S/4HANA

This option involves running SAP GTS as a standalone instance, separate from SAP S/4HANA.

Key Points:

  • Independent Operation: SAP GTS runs independently from SAP S/4HANA on a dedicated application server and database.

  • Integration Requirement: Integration interfaces are needed to enable data exchange between SAP GTS and S/4HANA.

  • Maintenance: Requires separate operational management, with updates and patches handled independently for SAP GTS.

  • Resource Efficiency: By processing system activities separately, this option reduces slightly the sizing requirements for SAP S/4HANA.

  • Landscape Requirements: With this approach would be required a SAP GTS System for every project environment, meaning: Development, Integration Test, User Acceptance Test, PreProduction, Production.
  • Increased Costs: This approach incurs higher costs due to the need for additional infrastructure and system resources.

  • Version Alignment: System components, such as SAP GTS and SAP S/4HANA, must be kept aligned in terms of versions to ensure smooth integration.


Evaluation

Based on the following matrix  Option A have been chosen :


Option A

Option B
Landscape Cost

(plus) Lower Costs


(minus) Higher Costs


Landscape Complexity

(plus) Simplified Landscape as there will be one instance to manage instead of two

(minus) More components per box

(minus) More complex landscape

(plus) Can tune boxes for specific tasks

Maintenance Complexity

(plus) Fewer boxes to patch

(minus) More dependencies

(minus) More boxes to patch

(plus) Fewer dependencies

Functional Scope(plus) Full Scope(plus) Full Scope
S/4HANA Resources Requirements(minus) Small Additional system requirements on S/4HANA(2/4 CPU,16/32GB RAM) since GTS process will run on the same instance(plus) System resources Full dedicated to GTS processes

Change log

Version Published Changed By Comment
CURRENT (v. 34) Mar 04, 2026 10:07 WENNINGER-ext, Sascha CR0279: Removed CUI instance following
v. 33 Jun 14, 2025 03:52 WENNINGER-ext, Sascha
v. 32 Jun 13, 2025 17:24 WENNINGER-ext, Sascha
v. 31 Jun 04, 2025 13:01 WENNINGER-ext, Sascha
v. 30 May 28, 2025 12:45 WENNINGER-ext, Sascha
v. 29 May 15, 2025 10:10 WENNINGER-ext, Sascha
v. 28 May 14, 2025 15:19 DANKIR-ext, Soukaina
v. 27 May 14, 2025 12:13 WENNINGER-ext, Sascha
v. 26 May 14, 2025 10:31 WENNINGER-ext, Sascha
v. 25 May 14, 2025 09:38 WENNINGER-ext, Sascha

Go to Page History