| Status | Approved |
| Owner | |
| Stakeholders | Marcela Anido, Jean Andrade |
| LeanIX Link | Vertex Cloud |
Introduction
Scope & Objectives
This document aims at describing the overall architecture of Vertex application in the SyWay context.
As per KDD093, SyWay will run Vertex Cloud solution (SaaS).
Key Decisions and Requirements
| Description | Rationale |
|---|---|
| Vertex Hosting | Following KDD093, Vertex Cloud is the solution |
| Vertex Cloud runs in EU region | Closer to S/4HANA for performance reason Following the overall hosting approach to host RoW applications in EU |
| Connected to S/4HANA RoW instance only | Vertex is primarily used for US tax calculations and thus is not required for China |
Terminology
VERTEX is an external software used by Syensqo to calculate taxes on customer and vendor invoices for US and Canadian legal entities. Tax Rules are customized by legal entities in VERTEX, based on Syensqo's Sales and Procurement processes. The tax rules customized in VERTEX are based on directions from the Syensqo USA Tax Department. Tax Jurisdiction Codes linked to the Country/State or Province/County/City/Postal Code are assigned to US and Canadian Customer and Vendor master data in SAP. Tax jurisdiction codes also are assigned to company codes, shipping points, and storage locations for the US and CA.
When a sales order, customer invoice/credit memo, purchase order, or vendor invoice/credit memo are processed in SAP, there is a Remote Function Call (RFC) from SAP to VERTEX to determine taxability of the transaction based on the customization. If the transaction is determined to be taxable, the tax rate is determined by the tax jurisdiction code specified on the customer, vendor, or plant/delivery address master record.
VERTEX issues monthly updates for tax rule changes, tax jurisdiction code changes, and tax rate changes. These monthly updates are applied to the VERTEX development, quality, and production servers to ensure tax calculations are correct.
Vertex Cloud is connected to its respective S/4 system through a component named SIC (SAP Interface Component).
Application Architecture
Overview
Today we have 6 SICs processes running in parallel for each ECC. This is for performance reason. We might review it later but we took the same initial design as target
Application Architecture Components
Vertex runs in S/4 systems through standard processes and transactions. . There are however dedicated objects to help on configuration, customization, monitoring and tax management. This list will depend on the additional tools and features purchased by Syensqo and are provided as external transports.
A specific RFC in S/4 calls the SIC processes, passing the required information onto them. The request is then sent against Vertex Cloud. Data is retrieved by SIC and sent back to the calling S/4. It uses SAP Jco and a J2EE engine.
Vertex Cloud operates the tax calculation and other activities. Syensqo IT team and tax department need accesses to Vertex Cloud to configure and manage their specific activities.
Network Architecture
Users will access Vertex cloud via their normal internet access
There is no end-user access required for SIC (only IT)
System Landscape
Vertex Cloud has 3 different environments : 1 for DEV, 1 for QAS, 1 for PROD. We will use different partitions (up to 4 available per instance) on Vertex Cloud to segregate the environments (Vertex partitions can be understood as the equivalent of an SAP client)
Syensqo will have 3 servers for running the SIC : 1 server serving as interface for all non-prods S/4 systems towards Vertex Cloud Dev and Qas. 2 servers in 2 differents AZ for production with multiple SIC running in parallel. It will provide HA and good response times.
The part residing in S/4 is for all S/4 RoW systems
Hosting Details
Vertex Cloud will be hosted in AWS EU region.
| Region | Localisation | Purpose | Infrastructure provider |
|---|---|---|---|
| EU | Frankfurt | Primary | AWS |
| EU | Dublin | DRP | AWS |
Vertex SIC will run on Syensqo Azure on dedicated RedHat servers hosted in Azure Paris.
System Access
The main usage of Vertex is done in background from SAP. IT team and Tax department will connect to the web page to proceed with some specific activities related to configuration.
URLs for the DEV, QAS, and PROD instances of Vertext will be recorded here once the instances are provisioned.
Application Security
Authentication
Syensqo users will connect through SSO to Vertex Cloud
There is a dedicated technical account for the connection from SIC to S/4
Authorisation
Authorisations in S/4 will be provided depending on the user roles. This is not covered in this document.
Authorisations in Vertex Application will be managed manually by the different teams.
Communication Security
Communication between SICs and Vertex Cloud is encrypted (HTTPS)
Communication between SICs and S/4 must be set as RFC with SNC encryption
Data Security
Credentials and TrustedIDs must be encrypted in SIC configuration file.
We shall enable the use of Trusted IDs and assign each partition to a Trusted ID. Trusted IDs do not allow anyone unathorized to log on to our system to change our tax data.
A Trusted ID is a partition-specific unique identifier that enables a secure connection where messages are exchanged between Vertex cloud products and an external system.
A partition represents a logical separation of data that is isolated from other logical data sets.
Each logical data set can be associated with a single entity or with multiple entities in a single system.
Multiple taxpayers can use the same partition.
Operation Architecture
Change and Configuration Management
Changes on S/4 will follow S/4 change management (see Transport Management for Release 4 DD-TEC-170)
Changes on SIC must be tested against the different non-productions environments and validated before proceeding with the production implementation.
Changes on Vertex Cloud must be tested and validated in DEV then QAS.
There is no tool to transport the changes between the different environments (SIC and Cloud), they have to be manually reproduced each time.
Monitoring
Monitoring of Vertex Cloud is part of Vertex contract. Different levels of support (Gold/Silver/Normal) and reactivity can be defined. SyWay selected the normal standard plan.
Vertex Cloud status can be checked here.
Monitoring of the SIC servers is done as other VMs in Azure (see Network and Infrastructure Architecture DD-TEC-070)
Sizing
Sizing of production is based on current O Series
Sizing of SIC servers depends on the number of SIC processes running. It is foreseen to use 3+3 SICs processes in parallel for production.
The hardware requirements are described below (see best recommendations)
High Availability & Disaster Recovery
SLA is 99.9% and obtained via Vertex Cloud running on 2 different regions in EU ( Primary is AWS Frankfurt with secondary in AWS Dublin)
SIC servers are deployed on 2 availability zones in Azure in order to achieve HA. All SICs processes register against the same RFC destination in S/4
Predefined SIC configuration files to address the DRP Vertex Cloud must be prepared and manually started in case of Vertex Cloud failover
Backup/Restore
Backups and restore are managed by Vertex in order to meet (or exceed) the below RPO/RTO
On the SIC server part, backups are scheduled following the Azure global backup strategy (see Azure Backup Policy)
Maintenance Plan
Vertex reserves a weekly recurring scheduled maintenance each sunday between 12AM and 6AM ET. Scheduled Maintenance windows will be published at least 72 hours in advance in the status page . Shorther publication period may however apply if a maintenance is required for security reasons.
SIC servers will follow standard Azure patching cycle. Update to SIC component itself will be done on demand.