High-Level Specification

Functional Overview

Currently, Icertis syncs Supplier Master Data with SAP Ariba Sourcing, capturing supplier names and details. However, SAP Ariba Sourcing does not store Purchasing Organization or Supplier Preferred Currency information. This creates a gap because:

• Purchasing Organization is essential for filtering suppliers and for passing accurate data to SAP ECC/S4 when creating an Outline Agreement.
• Supplier Currency is required for invoicing purposes and must be consistently maintained across systems

To bridge this gap, integration process  in SAP CPI is used to send Supplier details (Purchasing Organization and Supplier Preferred Currency) from Syniti to Icertis. This document describes the interface in SAP CPI which receives data from Syniti (ERP-555). SAP CPI will split the csv file received from Syniti into batches of 5000 records per file, name the files as per the standard naming convention (SupPorg_YYYYMMDDHHMMSS) accepted by Icertis Generic Integration Framework (GIF) and load the payload files in Azure Blob Storage hosted in Icertis Azure Subscription

Scope and Objectives

• Enable Icertis to receive and store Purchasing Organization and Supplier Preferred Currency for each supplier from Syniti via CPI in Supplier POrg and Currency Masterdata using GIF integration
• Ensure consistency of supplier master data across systems.
• Support full load during initial sync and full load updates daily.
• Syniti will generate and send a CSV file to CPI daily which will be sent to Icertis for further processing through GIF integration
• CPI will split the csv file received from Syniti into batches of 5000 records each.
• CPI will name the file as per the standard naming convention - SupPorg_YYYYMMDDHHMMSS

Sequence Diagram

Assumptions

• Supplier ID is unique and consistent across SAP and Icertis.

Dependencies

• Supplier integration from Ariba to Icertis should be executed before this load is executed
• Azure Blob Storage SAS Token must be active. 
• CPI should have write permission on the Blob Storage path where the csv load is placed. This permission is granted by Icertis. In case if CPI is unable to place the files in the Blob Storage, an Icertis Support Ticket is required requesting write access to the Blob Storage Account and Container.
• CPI to receive the full load in single csv file as per the payload format provided from Syniti
• Icertis will provide SAS URL Token which will be used by CPI for connecting to Blob.
•  The token expiry is set to 12 months
  • If the SAS URL token is expired, then IT Support Team should raise an Icertis Support Ticket to generate and configure new SAS URL in SAP CPI
  • Before expiry, IT Support Team can proactively request Icertis using support ticket to extend the validity of the SAS URL Token. As confirmed with Icertis, no reminder notification will be sent when SAS URL token is about to expire and an internal process needs to be defined within SyWay to monitor expiry of the SAS URL.

Security, Integrity and Controls

• CPI uses a time-limited, permission-scoped Shared Access Signature (SAS) token to authenticate with Azure Blob Storage. This ensures only authorized uploads are allowed, and the token cannot be used beyond its expiry date.
• The SAS token is scoped to the specific container and operation (write-only if possible), minimizing risk if the token is exposed.
• Unique, datestamped file names (e.g., SupPorg_DDMMYYYYHHMMSS.csv) prevent overwrites and support traceability.
• Only CPI (and authorized users/services) have the SAS token, and the token is extended before expiry.

Configuration Requirements

Technical Configuration

• Azure Blob Storage 

  • Storage account: syensqodevintegration
  • Container: integration
  • SAS URL (container‑scoped, HTTPS) - shared separately
  • Path: SupplierPurchaseOrgandCurrency_Dev/Inbox
     
• Payload Preparation & Batching
  • CSV payload: Supplier ID, POrg Code/Description, Preferred Currency, Status (Active/Inactive via ECC deletion flag).
  • Batching: Split into 5,000‑record per files to align with GIF ingestion and operational limits
  • Ensure the format of the batches should be exactly matching the csv payload sent by Syniti. 

  • Rationale for splitting the files into batches of 5000 records:

    As per Icertis Configuration Guide for GIF integration, the recommendation is to split the record into batches of 5000 records.

    

Functional Configuration

• Supplier Purchase POrg and Currency Masterdata Configuration must be created as per FS ERP-731

Special Requirements

• Not Applicable

Design Rationale

Data Structure

Source Structure (Syniti)

The following fields will be used to provide the required information for this interface:

Target Structure (Icertis)

The following fields will be used to provide the required information for this interface:

File Structure

Sample Payload:

Processing Logic

• SAP CPI receives the inbound Supplier POrg and Currency csv file from Syniti
• CPI will split the files in batches of 5000 records each.
• The naming convention will be SupPorg_YYYYMMDDHHMMSS.csv. As CPI can generate multiple files in one second, it is important to ensure that one file is generated per second to avoid duplicate naming of the payloads
• The processed data is transmitted to the Blob Storage Container 
• If any error occurs during transformation or routing, CPI logs the issue and stops further processing.
• The interface follows a full-load approach, either the entire batch is successfully processed or the batch is rejected in full.

Interface Dependency

Not Applicable

Interface Constraints

Not Applicable

Delivery Requirements

• CPI to process the file into multiple batches of 5000 records and send it to blob container

Sequencing

Not Applicable

Delta or Full Load Requirements

• The integration processes all records as a complete batch; if any issue occurs, the entire batch is rejected
• Initial full load - Syniti to send full of Supplier ID, Porg and Supplier Preferred Currency data. (Around 35000 suppliers)
• Daily updates- Every day, Syniti will send the full load of the suppliers.

Interface Alert & Monitoring

• Alerts should be configured for:
  • Failure while uploading file to blob
  • Email notification to be sent to IT Support Admin incase of upload failure
• Monitoring tools (middleware logs) should notify:
  • Integration support team
• Retry logic should be in place for transient failures.

Interface Reporting

Not Applicable

Language Requirements

Not Applicable

User Interface Requirements

Not Applicable

Volumetrics

• Daily load will be around 65000 suppliers information
• If PORG relationship is accounted for, then the total number of records transferred to Icertis will be over 100k

Performance Consideration

• As CPI instantly splits the csv payload received from Syniti into multiple batches. Icertis GIF integration accepts only one naming convention with YYYYMMDDHHMMSS time stamp. Due to this the files generated by CPI in one seconds will have the same file name resulting in override and duplicity.
• It is recommended to generate the file batches of 5000 records per file with a delay of 1 seconds, meaning 1 file per second to be generated by CPI to ensure that file names are unique.

Error Handling

• SAS Token Expired/Connection Lost: CPI to send email notification to IT Support Team stating unable to connect with Azure Blob Storage
• CPI to retry 3 times every 1 hour to push the failed files to Blob Storage. If connection is still down even after 3 retries, files will be moved to Deadlock queue in CPI

Testing

How to Test

1. Split the csv received from Syniti into multiple batches of 5000 records each, push it to Blob Container
2. Naming convention of the files are generated correctly

Test Conditions and Expected Results

Test Considerations/Dependencies

Not Applicable

Other Information

Mechanics of Azure Blob Storage

Azure Blob Storage is a distributed, replicated, object storage system where data lives as blobs inside containers within a storage account, exposed via HTTP APIs, auto‑scaled globally, tiered for cost, and secured through Azure identity & network controls. It is an object storage, designed for massive amounts of unstructured data. Its mechanics are built around three core layers:

• Storage Account - (the root namespace)
  • Everything starts with an Azure Storage Account, which acts as:
    • the unique namespace for all your blobs
    • the billing boundary
    • the container for redundancy, network rules, and performance tier
• Containers (logical folders)
  • A container organizes blob.
  • It cannot be nested, means we cannot create a container within another container. There won't be any sub-containers or child containers
  • defines default access levels
  • uses naming rules (lowercase, no spaces, hyphens allowed)
  • Containers help group logs, media, backups etc
• Blobs (actual data objects)
  • Actual files, media, logs are stored as blob
• Access Mechanism
  • There are two ways in which SAP CPI can access Azure Blob
    • Using SAP Azure Storage Adaptor
      • SAP provides an adaptor that supports CRUD operations for Azure Storage services. The blob can be authenticated using
        • SAS Token
        • Shared Access Key
    • Using CPI REST/HTTP Adapter and Azure Blob REST API

Development Details

Package

Other Development Objects

 Security Material

Appendix

Sample Payload of CSV file expected by Icertis from Syniti. Refer "Payload in CSV" worksheet

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log