- SAP Managed Tags
Introduction
While learning SAP Cloud Integration (CPI), I wanted to work on a practical, real‑time use case rather than a basic file‑based or sample integration. In many real projects, applications need to handle multiple currencies because of global customers, suppliers, and financial transactions.
To understand how CPI handles API‑based synchronous integrations, I decided to build a currency conversion iFlow. The objective was to expose an HTTPS endpoint, call an external currency conversion API, and return the converted amount in a readable format. Along with the happy path, I also wanted to implement proper exception handling, similar to what is expected in real production scenarios.
This blog shares my design approach, iFlow structure, and key learnings from implementing this scenario.
Business Requirement
The requirements I considered while designing this iFlow were:
- Convert an amount from one currency to another in real time
- Expose the functionality through a secure HTTPS endpoint
- Fetch up‑to‑date exchange rates from an external API
- Return the result in a user‑friendly output
- Handle errors in a centralized and structured way
This closely mimics real‑world requirements where CPI acts as an integration layer between business applications and external services.
High‑Level Solution Overview
I designed the solution using SAP Cloud Integration following a simple API‑to‑API pattern:
- An external system sends a currency conversion request.
- CPI receives and processes the request.
- CPI calls an external currency conversion API.
- CPI formats the response as an HTML output.
- In case of any failure, CPI handles errors through an Exception Subprocess and sends notifications.
This approach helped me understand how CPI manages synchronous calls, properties, transformations, and error handling together.
iFlow Design Overview
The iFlow is divided into two main parts:
- Main Integration Flow – handles the successful processing
- Global Exception Subprocess – handles errors from any step in the flow
This separation made the design clean and easier to maintain.
I-FLow.
Main Integration Flow – Step‑by‑Step
HTTPS_In
This step starts the message processing and generates the Message Processing Log (MPL) ID, which is useful for monitoring and troubleshooting.
Why I used it:
Most real‑time integrations in CPI are API‑driven, so HTTPS was the natural choice.
HTTPS sender adapter configuration.
You can choose your own address name.
JSON2XML_Convert
Learning:
Converting early helps avoid complications in later steps.
Set_ConvParams (Content Modifier)
I purposely used properties instead of reading values repeatedly from the payload, as this improves readability and reusability across the flow.
Why I did this:
Using properties keeps later steps independent of payload structure.
Content Modifier (Properties tab)
Call_RateAPI
During testing, I intentionally triggered API errors to verify whether my exception handling was working correctly.
Learning:
Request‑Reply is ideal when immediate responses are required.
Build_HTML_Result
Instead of returning raw JSON or plain text, I formatted the result as an HTML table containing:
- Source currency
- Target currency
- Source amount
- Converted amount
- Timestamp (IST)
Why I did this:
HTML output improves readability for users, testers, and demos.
HTTP_Out
Use case:
This is very helpful during testing and demonstrations without needing a separate UI.
Exception Subprocess – Centralized Error Handling
While building the flow, I realized that handling only the success scenario was not enough. So I implemented a Global Exception Subprocess to handle failures consistently.
Err_Start
This step is triggered automatically whenever an error occurs in any part of the main flow, such as:
- API failures
- Groovy errors
- Payload or conversion issues
Err_Build_HTML
In this step, I extracted error details such as:
- MPL ID
- Error type
- Error message
- Timestamp
I formatted these details into an HTML table, similar to the success response. This made the error output structured and easy to understand.
Learning:
Readable error messages save a lot of troubleshooting time.
Mail_Out_Err
I added a Mail adapter to send the formatted error details to a support email ID. This ensures that failures are noticed immediately without checking CPI logs manually.
Real‑world relevance:
This is commonly used in production environments for monitoring.
Err_End
The exception flow ends cleanly after sending the notification, ensuring proper message lifecycle completion.
The above one is for incorrect input payload
Benefits of This Approach
- Practical understanding of API‑based integrations in SAP CPI
- Importance of Exchange Properties for clean design
- How to implement a reusable Exception Subprocess
- Benefits of HTML‑formatted responses for both success and errors
- How CPL logs (MPL ID) help in monitoring and support
Conclusion
This exercise helped me gain hands‑on experience in building a real‑time integration scenario using SAP Cloud Integration. By implementing both success and error handling properly, I was able to design an iFlow that closely resembles a real‑world project.
The same design pattern can be reused for many API‑driven integration scenarios, making it a valuable learning experience.
Bluesky| User | Count |
|---|---|
| 35 | |
| 10 | |
| 9 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 3 |
