High- Level Specification

Functional Overview

The requirement is to build the middleware integration process that manages both inbound and outbound interfaces between Syniti and 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 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.
  • Address gaps in SAP Standard, which does not natively support direct integration between Syniti and ICertis for currency master data. This interface fills that gap by providing custom mapping and orchestration.

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).
• Exception handling is in place for failed transmissions or data mismatches.

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 Syniti and ICertis.
• Data mapping rules (currency codes, exchange rate formats).
• Scheduling configuration for batch triggers.
• 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:

Calculation and Validation

Processing Logic

• The integration job runs on the 1st of each month.
• It fetches exchange rates from Syniti for the last day of the previous month.
• The data is transformed into the required format and pushed to Icertis via the Business API.
• The API performs bulk upsert: updates existing records or creates new ones.
• Errors are logged and flagged for manual review.

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 monthly.

Language Requirements

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

User Interface Requirements

Not Applicable

Volumetrics

Not Applicable

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 record.
  • 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:
  • Retry up to 3 times with exponential backoff.
  • 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:
  • Log both successful and failed records.
  • Generate a summary report for review.
  • Provide reprocessing option for failed records.

5. Missing Data from Syniti

• Cause: Exchange rate data not available on schedule.
• Handling:
  • Alert business users and integration team.
  • Optionally use previous month’s rates (if approved by business).
  • Flag contracts that rely on missing data for manual review.

6. Monitoring and Alerts

• Tools: Integration monitoring dashboard, email notifications, log files.
• Recipients: Integration support team, business operations team.
• Alert Types:
  • Job success/failure
  • Record-level validation errors
  • API connectivity issues
  • Missing or delayed data

 Interface Alert & Monitoring

• Alerts should be configured for:
  • API failures
  • Missing or incomplete data
  • 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

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