Introduction
Middleware migrations are rarely just about converting interfaces. The harder part is often keeping the architectural capabilities that made the old landscape maintainable.
On a recent project migrating interfaces from Software AG webMethods to SAP Integration Suite, the client had a clear requirement. In webMethods, each application kept its configuration centrally as key-value properties, and many integration services read from that one source. The client wanted the same model in Cloud Integration. They did not want to copy the same properties into dozens of iFlows, and they did not want to add an external configuration repository.
The solution came from a feature that is usually associated with B2B scenarios: the Cloud Integration Partner Directory.
This post covers:
- Why we chose Partner Directory over the other options
- The target architecture
- A reusable Groovy utility for configuration lookup
- How this compares with configuration and caching patterns in webMethods and Boomi
- The operational points to evaluate before using it in production
1. The Challenge
Picture an application with about 50 integration services and 100 application-level properties, such as:
- Application identifiers and processing flags
- Retry limits and intervals
- File naming conventions
- Notification settings
- Routing identifiers
- Business-specific processing parameters
In webMethods, these lived in one place and every service read from that same source. Copying them into externalized parameters on 50 separate iFlows would multiply the maintenance work and make configuration drift almost certain.
The requirement was centralized configuration with runtime lookup, built only on native SAP Integration Suite capabilities.
2. Options We Evaluated
| Capability | Assessment for this requirement |
| Externalized Parameters | Well suited to iFlow-specific settings. Not designed as a shared repository across independent iFlows. |
| Value Mapping | Built for value translation between agencies and identifiers. A poor fit for managing a whole application configuration. |
| Data Store | Offers persistence, but adds design effort for the configuration lifecycle, maintenance and access. |
| Security Material | The right place for credentials and secrets. Not for general configuration. |
| Partner Directory | A tenant-level parameter repository that supports String and Binary parameters, can be read at runtime by any iFlow, and can be maintained through an API. |
Partner Directory met the requirement most directly. Maintaining 100 separate String parameters would be tedious, so we grouped each application's properties into one UTF-8 properties file stored as a Binary Parameter.
3. Target Architecture
The design has three parts:
- Partner Directory holds one configuration file per application as a Binary Parameter.
- A reusable Groovy utility, delivered through a Script Collection, retrieves the file, parses it and exposes the requested values.
- Consuming iFlows call the shared utility. None of them implement their own retrieval logic.
| Partner ID | Parameter ID | Purpose |
| MOBILE_APP | APP_CONFIG | Mobile application configuration |
| FINANCE_APP | APP_CONFIG | Finance application configuration |
| HR_APP | APP_CONFIG | HR application configuration |
The Partner ID separates configuration by application. Using the same Parameter ID for every application keeps the lookup logic identical everywhere.
The diagram below illustrates Partner Directory runtime caching, including cache hits, cache misses, and LRU eviction.
4. Sample Configuration File
# Application Settings
Application.Name=DEMO_APP
Application.Environment=DEV
# Processing Configuration
Processing.Enabled=true
Processing.BatchSize=100
# Retry Configuration
Retry.MaxAttempts=5
Retry.IntervalSeconds=30
# Notification Configuration
Notification.Enabled=true
[email protected]
# File Processing
File.Encoding=UTF-8
File.ArchiveEnabled=true
This file is stored as a Binary Parameter with:
- Partner ID:
DEMO_APP - Parameter ID:
APP_CONFIG - Content type: text (UTF-8)
The whole application configuration is one logical, versionable object, so nobody has to manage 100 parameters one at a time.
5. Reusable Groovy Utility
Cloud Integration exposes Partner Directory to scripts through the PartnerDirectoryService API. The utility below:
- Reads the Partner ID and Parameter ID from exchange properties, so the same script works for any application
- Fails fast with a clear message if the configuration or a required key is missing
- Writes each value to an exchange property
import com.sap.gateway.ip.core.customdev.util.Message
import com.sap.it.api.ITApiFactory
import com.sap.it.api.pd.PartnerDirectoryService
import com.sap.it.api.pd.BinaryData
import java.nio.charset.StandardCharsets
def Message processData(Message message) {
// ================================================
// 1. Partner Directory Configuration
// ================================================
String pid = "DEMO_APP"
String parameterId = "APP_CONFIG"
def pdService = ITApiFactory.getService(
PartnerDirectoryService.class, null
)
if (pdService == null) {
throw new Exception(
"Partner Directory Service is unavailable"
)
}
// ================================================
// 2. Read Binary Parameter
// ================================================
BinaryData parameter = pdService.getParameter(
parameterId,
pid,
BinaryData.class
)
if (parameter == null) {
throw new Exception(
"Partner Directory configuration not found: " +
pid + "/" + parameterId
)
}
// Convert binary data into UTF-8 text
String content = new String(
parameter.getData(),
StandardCharsets.UTF_8
)
// ================================================
// 3. Prepare Monitoring Attachment
// ================================================
StringBuilder attachment = new StringBuilder()
attachment.append(
"SAP CPI - Partner Directory Configuration\n"
)
attachment.append(
"=========================================\n"
)
attachment.append("Partner ID : ${pid}\n")
attachment.append("Parameter : ${parameterId}\n")
attachment.append(
"=========================================\n\n"
)
int count = 0
// ================================================
// 4. Parse Key-Value Pairs
// ================================================
content.eachLine { String rawLine ->
String line = rawLine.trim()
// Ignore blank lines and comments
if (!line || line.startsWith("#")) {
return
}
int separator = line.indexOf("=")
if (separator > 0) {
String key = line.substring(
0, separator
).trim()
String value = line.substring(
separator + 1
).trim()
// Create Exchange Property
message.setProperty(key, value)
// Add to monitoring attachment
attachment.append(
"${key} = ${value}\n"
)
count++
}
}
// Store total count
message.setProperty(
"Config_PropertiesLoaded", count
)
// ================================================
// 5. Add Property Count
// ================================================
attachment.append(
"\n=========================================\n"
)
attachment.append(
"Total Properties Loaded: ${count}\n"
)
attachment.append(
"=========================================\n"
)
// ================================================
// 6. Add Usage Examples
// ================================================
attachment.append('''
HOW TO ACCESS PROPERTIES IN SAP CPI IFLOW
=========================================
# Example 1: Content Modifier / Router
# Syntax:
# ${property.<PropertyName>}
${property.Application.Name}
${property.Application.Environment}
# Example 2: Groovy Script
# Syntax:
# message.getProperty("<PropertyName>")
def appName = message.getProperty("Application.Name")
def timeout = message.getProperty("Application.Environment")
# NOTE:
# All properties are dynamically loaded from
# SAP Partner Directory into Exchange Properties.
#
# These properties are available to subsequent
# steps within the same message exchange.
#
# Updating configuration values in Partner
# Directory does not require iFlow redeployment.
=========================================
END OF CONFIGURATION
=========================================
''')
// ================================================
// 7. Write MPL Attachment
// ================================================
def messageLog = messageLogFactory.getMessageLog(
message
)
if (messageLog != null) {
messageLog.addAttachmentAsString(
"PartnerDirectory_Configuration.txt",
attachment.toString(),
"text/plain"
)
}
return message
}Usage in an iFlow:
- Add a Content Modifier that sets these exchange properties:
AppConfig_PartnerId=DEMO_APPAppConfig_ParameterId=APP_CONFIGAppConfig_Keys=Retry.MaxAttempts,Retry.IntervalSeconds,Notification.Email
- Call the script from a shared Script Collection.
- Reference the values downstream, for example
${property.Retry_MaxAttempts}.
The script parses the file once per call and returns every requested key in a single step. For production use, you can extend it with optional keys and defaults, type validation (integer or boolean), and a standard error-handling convention.
6. How Does This Compare with webMethods and Boomi?
Both platforms offer several ways to externalize configuration and cache values. In webMethods, examples include package-level configuration files, Global Variables and Cache Manager. In Boomi, examples include Environment Extensions and Document Caches. Partner Directory supports the same pattern for persistent configuration read repeatedly at runtime, but it is not a one-for-one replacement.
| Capability | webMethods / Boomi patterns | SAP Partner Directory approach |
| Centralized configuration | Supported | Supported |
| Reuse across interfaces | Supported | Supported |
| Key-value lookup | Native | Through Groovy parsing |
| Application-level grouping | Supported | Through Partner IDs |
| Runtime retrieval | Supported | Supported |
| Runtime caching | Depends on mechanism | Managed by SAP |
| Explicit cache lifecycle control (TTL, eviction, refresh) | Depends on mechanism | Limited |
| Update without redeployment | Depends on mechanism | Supported, subject to cache propagation |
The key point: Partner Directory is a persistent parameter repository with SAP-managed caching. It is not a general-purpose cache. Do not use it for transient, high-churn or transactional data. For relatively static application configuration, it works well.
7. Operational Considerations
Caching and propagation. The runtime caches Partner Directory parameters, so a change may not reach every worker node immediately. If a scenario needs immediate consistency after a change, plan for that, and test the propagation behavior on your own tenant.
Security. Partner Directory is not a secrets vault. Keep credentials, tokens and keys in Security Material or the appropriate security services. Keep secrets out of the properties file.
Size limits. Binary parameters have a documented size limit, and the tenant has overall resource limits. Check both before putting a large configuration into one file. Splitting it by functional area under separate Parameter IDs is a simple fallback.
Runtime overhead. Each call retrieves and parses the file. This is negligible for most scenarios, but measure it for high-volume interfaces. Load the configuration once per message, not once per key.
Transport between tenants. Partner Directory content is not transported with integration packages. Use the Partner Directory OData API (Binary Parameters) to promote configuration across DEV, QA and PRD, ideally from a version-controlled source as part of your CI/CD pipeline. This also gives you a clean audit trail and rollback path.
Governance. Define ownership, change approval, validation and rollback for configuration changes. Configuration changes can affect production behavior as much as code changes can.
Tenant scope. Parameters belong to a single Cloud Integration tenant. Do not use Partner Directory as a cross-tenant configuration store.
8. Benefits for Middleware Migration
- Keeps a familiar architecture. Teams coming from webMethods keep a centralized configuration lookup model.
- Removes duplication. Shared properties live in one place, not in every iFlow.
- Standardizes access. One shared Groovy utility gives every iFlow consistent lookup and error handling.
- Separates configuration from code. Configuration changes do not require iFlow changes or redeployment.
- Stays SAP-native. No external configuration service is needed.
9. A Suggestion to SAP: Manual Cache Invalidation and Refresh
While SAP Cloud Integration automatically manages Partner Directory caching and invalidates cached entries when parameters are updated, cache propagation across runtime nodes can take a few minutes.
It would be valuable if SAP introduced an option to manually invalidate or refresh the Partner Directory cache, either through the Manage Partner Directory UI or a dedicated administrative API.
This would give integration administrators greater control over configuration changes, particularly in scenarios where updated application parameters need to take effect immediately without waiting for automatic cache propagation.
Such a capability would make Partner Directory even more attractive as a centralized configuration repository for enterprise integration landscapes.
10. Conclusion
Modernizing middleware means keeping the capabilities that make an integration landscape maintainable, not only migrating interfaces.
In this webMethods-to-SAP Integration Suite migration, centralized application configuration was one of those capabilities. Partner Directory Binary Parameters combined with a reusable Groovy utility gave us a clean, SAP-native way to manage configuration centrally and read it dynamically across many iFlows.
It does not replace every caching feature of webMethods or Boomi, but for relatively static configuration it is practical and easy to govern.
Some of the most useful patterns come from using SAP capabilities beyond their usual scenarios.
Have you used Partner Directory for configuration management outside B2B? I'd like to hear how other teams have handled similar migration requirements. Please share in the comments
References
1. SAP Help Portal – Partner Directory
https://help.sap.com/docs/cloud-integration/sap-cloud-integration/partner-directory
Overview of Partner Directory architecture, entities, and runtime parameterization.
2. SAP Help Portal – Parameterizing Integration Flows Using the Partner Directory
https://help.sap.com/docs/CLOUD_INTEGRATION/368c481cd6954bdfa5d0435479fd4eaf/b7812a546ab14de6aa0a7c9...
Explains how integration flows dynamically retrieve centrally maintained configuration values.
3. SAP Business Accelerator Hub – Partner Directory API (Cloud Integration)
https://api.sap.com/api/PartnerDirectory/
Official OData API for creating, updating, retrieving, and deleting Partner Directory entries.
4. SAP Community – Cloud Integration: Partner Directory – Step-by-Step Example
https://community.sap.com/t5/technology-blog-posts-by-sap/cloud-integration-partner-directory-step-b...
SAP Community article demonstrating practical Partner Directory implementation.
5. SAP Help Portal – Read and Modify Partner Directory Content
https://help.sap.com/docs/integration-suite/sap-integration-suite/read-and-modify-partner-directory-...
Particularly relevant to your Groovy-based approach for retrieving reusable configuration properties.
6. SAP Help Portal – Managing Partner Directory Entries
https://help.sap.com/docs/cloud-integration/sap-cloud-integration/managing-partner-directory-entries
Explains how to maintain String and Binary Parameters through the SAP Integration Suite monitoring interface.
7. SAP Help Portal – Use the Partner Directory Appropriately
https://help.sap.com/docs/cloud-integration/sap-cloud-integration/use-partner-directory-appropriatel...
SAP's recommended design guidelines for using Partner Directory.
Sample Implementation:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.