High- Level Specification

Functional Overview

The requirement is to build the middleware integration process that manages the outbound of Currency Exchange Masterdata from Syniti and inbound to Icertis. It is responsible for:

• Receiving currency/exchange rate data from Syniti (via FS-288).
• Mapping and transforming this data to match the requirements of ICertis APIs.
• Orchestrating the data flow, ensuring successful transmission and error handling. This integration is triggered daily by a scheduled job, ensuring that Icertis always has the latest exchange rates for contract processing.

Scope and Objectives

• Scope:
  This request covers the end-to-end integration logic required to fetch, transform, and deliver currency/exchange rate data from Syniti to Icertis.
• Objectives:
  • Automate the transfer of currency/exchange rate data.
  • Ensure data is mapped to ICertis API specifications.
  • Handle exceptions and retries for robust data delivery.
  • This interface fills the gap by providing custom mapping and orchestration between Syniti and Icertis for Currency Exchange Rate.

Process Flow Diagram

Assumptions

• Syniti provides clean, validated currency/exchange rate data.
• Icertis APIs are available and documented for currency master data ingestion.
• Middleware platform supports secure API calls, error handling, and logging.
• Performance requirements are met (e.g., data transfer completes within batch window).

Dependencies

• Availability of FS-288 (Syniti interface) and FS-290 (Icertis interface).
• Access to Syniti and Icertis environments for development and testing.
• Timely updates to currency/exchange rate data in Syniti.
• Coordination with SAP and Icertis teams for API changes or enhancements.
• Batch jobs or triggers in Syniti must run before FS-289 executes.

Security, Integrity and Controls

• Secure authentication for middleware to access Syniti and ICertis (API keys, certificates).
• Audit logging for all integration transactions.

Configuration Requirements

• API endpoints and credentials for Icertis.
• Data mapping rules in CPI and Icertis (currency codes, exchange rate formats).
• Error handling and retry parameters.
• Logging and monitoring setup.

Design Rationale

This interface is designed to facilitate seamless integration between Syniti (source) and Icertis (target) for currency/exchange rate master data. The middleware orchestrates the data flow, ensuring mapping, transformation, and reliable delivery

Data Structure

The following fields will be used to provide the required data structure of the interface:

Requested Sample (Extract from ECC):

 Currency conversion file generated as per ERP-110 Currency Conversion into Ariba (Syniti Interface) FS should be re-used for Icertis as well. CPI will filter out the EUR conversion rate.

 Transformation in Syniti (Icertis required format):

Processing Logic

• Inbound Trigger

  • CPI receives the currency conversion data file from Syniti

• Data Validation

  • If any record fails validation, CPI rejects the entire batch and sends an error notification to Syniti/integration support.

• Transformation

  • CPI applies any required transformation rules:
    • Maps Syniti field names/formats to the target structure required by Icertis

• Routing

  • CPI routes the validated  data to the next integration step (e.g., prepares payload for Icertis Business API).
  • Ensures secure transmission (e.g., via HTTPS, OAuth2).

• Error Handling

  • If any error occurs during processing (validation, transformation, routing), CPI logs the error, stops the process, and sends an alert to the integration support team.
  • No partial loads—either the entire batch is processed successfully, or it is rejected.

• Monitoring & Logging

  • CPI maintains detailed logs for each integration run.
  • Job status, error details, and audit trails are available on the CPI monitoring dashboard.
  • Email alerts are sent for failures.

Delta or Full Load Requirements

• Full Load:
  • The interface always pushes the complete set of exchange rates for all supported currencies.
  • No delta tracking is required since the data is refreshed daily.

Language Requirements

• No multilingual support required for exchange rate data.
• All fields are numeric or standard ISO codes.

User Interface Requirements

Not Applicable

Volumetrics

• Daily load of 70 currency pairs to be created/updated in bulk
• The first load will create the currency exchange masterdata
• Subsequent loads will update the existing currency exchange masterdata

Performance Consideration

Scheduling and Execution Window

• The integration job should be scheduled during off-peak hours (e.g., early morning on the 1st of each month) to avoid contention with other system processes.

Error Handling

1. Validation Errors

• Cause: Missing mandatory fields, invalid currency codes, negative exchange rates.
• Handling:
  • Reject the whole batch.
  • Log the error with detailed message.
  • Notify integration support team via email or dashboard.
  • Continue processing remaining records.

2. API Failures

• Cause: Icertis Business API is unavailable, authentication failure, timeout.
• Handling:
  • If retries fail, log the failure and raise an alert.
  • Notify support team with error code and timestamp.

3. Data Load Failures

• Cause: Payload formatting issues, bulk upsert failure.
• Handling:
  • Validate payload structure before submission.
  • Use staging logs to identify failed records.
  • Allow manual reprocessing of failed records.

4. Partial Success

• Cause: Some records succeed, others fail due to validation or API issues.
• Handling:
  • Reject the whole record and notify the admin team on failure

5. Monitoring and Alerts

• Tools: Integration monitoring dashboard, email notifications, log files.
• Recipients: Integration support team, business operations team.
• Alert Types:
  • Job failure

 Interface Alert & Monitoring

• Alerts should be configured for:
  • API failures
  • Validation errors
• Monitoring tools (middleware logs) should notify:
  • Integration support team
  • Business users (email)
• Retry logic should be in place for transient failures.

Testing

Test Conditions and Expected Results

Test Considerations/Dependencies

Development Details

Package

Other Development Objects

Appendix

Sample payload:

{

  "Messages": null,

  "Data": {

    "ContractTypeName": "ICMCurrencyExchangeRate",

    "JobItems": [

      {

        "NextState": "",

        "RequestIdentifier": 1,

        "EndpointVersion": null,

        "UseExternalId": true,

        "SysId": "",

        "RequestBody": {

          "ICMUniqueName": "",

          "Name": "Masterdata_1_created",

          "ICMFromCurrency": "",

          "ICMAgreementCode": "",

          "ICMToCurrency": "",

           "ICMRate": "",

          }

        },

        "TemplateSelection": "none",

        "EndPointVersion": 1

      },

      {

        "NextState": "",

        "RequestIdentifier": 2,

        "EndpointVersion": null,

        "UseExternalId": false,

        "SysId": "",

        "RequestBody": {

         "ICMUniqueName": "",

          "Name": "Masterdata_2_created",

          "ICMFromCurrency": "",

          "ICMAgreementCode": "",

          "ICMToCurrency": "",

           "ICMRate": "",

          }

        },

        "TemplateSelection": "none",

        "EndPointVersion": 1

      }

    ]

  },

  "HasMoreData": false,

  "PagingData": null

}

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