Policies: A New Approach to Configurable Services in App Connect Enterprise

Published on 20 August 2023 | 951 words, 5 min read
#blog #ibm #ace #iib #integration #ace-v12 #iib-v10 #policies #configurable-services
Policies: A New Approach to Configurable Services in App Connect Enterprise

Bridging the Gap: IIB Configurable Services vs. ACE Policies

In the ever-evolving landscape of integration solutions, IBM has played a pivotal role in providing tools that empower businesses to seamlessly connect their applications and systems. Two key components in this journey are IBM Integration Bus (IIB) Configurable Services and IBM App Connect Enterprise (ACE) Policies. In this article, we'll delve into the characteristics of both, draw comparisons, and guide you through a detailed example illustrating how to migrate from IIB Configurable Services to ACE Policies.

Understanding IIB Configurable Services

In IBM Integration Bus (IIB), Configurable Services have long been a cornerstone for building flexible and reusable integration solutions. Configurable Services enable the dynamic configuration of integration flows by allowing parameters to be defined and modified without altering the underlying ESQL code. This flexibility is especially beneficial in scenarios where runtime adjustments are necessary without requiring a redeployment of the entire integration.

Key features of IIB Configurable Services include:

  1. Parameterization: Configurable Services allow users to define parameters that can be set and modified during runtime. These parameters act as dynamic placeholders within the integration flow, enabling adaptability to changing requirements.

  2. Dynamic Configuration: The ability to alter configurations without altering the ESQL code is a defining characteristic of Configurable Services. This makes IIB Configurable Services suitable for scenarios where frequent changes are anticipated, such as adapting to varying endpoint URLs or adjusting processing thresholds.

  3. Reusability: Configurable Services promote the creation of reusable integration components. Once configured, a service can be applied across multiple integration flows, fostering consistency and reducing development effort.

Introducing ACE Policies

With the evolution from IIB to IBM App Connect Enterprise (ACE), Policies have emerged as the successor to Configurable Services. ACE Policies retain the essence of dynamic configuration while introducing enhancements to meet the demands of modern integration architectures. Let's explore the key features of ACE Policies:

  1. Dynamic Properties: Similar to Configurable Services, ACE Policies offer dynamic properties that can be adjusted at runtime. This ensures that changes can be made without requiring a redeployment, contributing to the agility required in dynamic business environments.

  2. Centralized Configuration: ACE Policies provide a centralized approach to configuration management. Configuration data is stored in a separate externalized location, allowing for easier management and potential integration with external configuration management systems.

  3. Enhanced Reusability: ACE Policies take reusability a step further by providing a centralized repository for policies. This repository enables the reuse of policies across different integration projects, fostering a standardized approach to configuration.

Migrating from IIB Configurable Services to ACE Policies: A Detailed Example

To illustrate the migration process from IIB Configurable Services to ACE Policies, let's consider a scenario where a configurable service is used in FTP connection scenario.

Integration Node Command Line (Sample):

mqsicreateconfigurableservice IBNODE -c FtpServer -o Server01 -n serverName,scanDelay,transferMode,connectionType,securityIdentity -v ftp.example.com:3334,10,BINARY,PASIVE,secId

Integration Node Configurable Service File Contents (FTPConfig.yaml):

FTPServer: ftp.example.com
FTPUser: username
FTPPassword: password
FTPDirectory: /upload

IIB ESQL Code Utilizing Configurable Service:

-- FTP Configurable Service Parameters
DECLARE FTPServer CHARACTER;
DECLARE FTPUser CHARACTER;
DECLARE FTPPassword CHARACTER;
DECLARE FTPDirectory CHARACTER;

-- Retrieve FTP Configurations
SET FTPServer = ConfigurableServices.FTPService.FTPServer;
SET FTPUser = ConfigurableServices.FTPService.FTPUser;
SET FTPPassword = ConfigurableServices.FTPService.FTPPassword;
SET FTPDirectory = ConfigurableServices.FTPService.FTPDirectory;

-- FTP Logic (Sample)
CALL FTPOutputMessage('file.txt', FTPServer, FTPUser, FTPPassword, FTPDirectory);

ACE FTP Policy Example:

ACE FTP Policy File Contents (FTPPolicy.yaml):

FTPServer: ftp.example.com
FTPUser: username
FTPPassword: password
FTPDirectory: /upload

ACE Integration Application Policy Reference:

Policies:
  - FTPPolicy.yaml

ACE ESQL Code Utilizing FTP Policy:

-- FTP Policy Parameters (Externalized)
DECLARE FTPServer CHARACTER;
DECLARE FTPUser CHARACTER;
DECLARE FTPPassword CHARACTER;
DECLARE FTPDirectory CHARACTER;

-- Retrieve FTP Configurations
SET FTPServer = LocalEnvironment.Policy.FTPPolicy.FTPServer;
SET FTPUser = LocalEnvironment.Policy.FTPPolicy.FTPUser;
SET FTPPassword = LocalEnvironment.Policy.FTPPolicy.FTPPassword;
SET FTPDirectory = LocalEnvironment.Policy.FTPPolicy.FTPDirectory;

-- FTP Logic (Sample)
CALL FTPOutputMessage('file.txt', FTPServer, FTPUser, FTPPassword, FTPDirectory);

Key Differences and Considerations:

  1. Externalized Parameter Access:

    • In IIB Configurable Services, parameters are accessed via ConfigurableServices namespace.
    • In ACE Policies, parameters are accessed via LocalEnvironment.Policy namespace.

  2. Policy File vs. Configurable Service File:

    • IIB uses .yaml files for Configurable Services (e.g., FTPConfig.yaml).
    • ACE uses .yaml files for Policies (e.g., FTPPolicy.yaml).

  3. Policy Reference in ACE Integration Application:

    • ACE Integration Applications reference Policies in the application YAML file under the Policies section.

  4. Tool Commands:

    • IIB Configurable Services are created using mqsicreateconfigurableservice command.
    • ACE Policies are compiled into a BAR file and deployed.

  5. ESQL Code Structure:

    • ESQL code structure remains similar between IIB and ACE, with differences in how externalized parameters are accessed.

By comparing these examples, we can observe the transition from IIB Configurable Services to ACE Policies. The externalized parameter access and the way policies are referenced in ACE signify the evolution toward a more centralized and standardized approach in ACE.

Feel free to adapt the FTP logic and parameters based on your specific FTP requirements and environment.

Conclusion

In the realm of IBM integration solutions, the transition from IIB Configurable Services to ACE Policies marks a progression toward more dynamic, centralized, and reusable configuration management. While Configurable Services have served as a stalwart in flexible integration development, ACE Policies build upon these principles, addressing the evolving needs of modern integration architectures.

As organizations embark on this migration journey, understanding the key features of both IIB Configurable Services and ACE Policies is crucial. The provided example offers a practical insight into the migration process, showcasing how to adapt existing logic to the enhanced capabilities of ACE Policies.

Ultimately the goal remains the same: to build integration solutions that are agile, adaptable, and capable of meeting the dynamic demands of today's interconnected business landscape.