| Policy Name | Execution Location | Explanation |
| 1. validate-usernametoken | DataPower Gateway | This is a core WS-Security policy for validating SOAP message security. DataPower is specifically designed for this type of XML/SOAP security processing. |
| 2. token-mediation | DataPower Gateway | This policy mediates between different token types (e.g., validating an OAuth token and generating a JWT for a backend). This is a critical runtime security function. |
| 3. extract | DataPower Gateway | This policy extracts values from the request/response (headers, body, path) for use in other policies. This is fundamental message processing. |
| 4. parse | DataPower Gateway | This policy parses the message body (e.g., JSON, XML, form-data) into a structured context variable for manipulation. This is a core runtime processing step. |
| 5. validate | DataPower Gateway | This policy validates a message body against a schema (JSON Schema, XML Schema). This is a standard API gateway data validation function. |
| 6. ratelimit | DataPower Gateway | This policy enforces rate limits on API calls. It checks and updates counters in real-time, which is a primary function of the gateway runtime. |
| 7. invoke | DataPower Gateway | This is the policy that actually calls (invokes) a backend service or another API. This is the core routing and proxying function of the gateway. |
| 8. map | DataPower Gateway | This policy maps data from one format/structure to another (e.g., using a GraphQL schema). This is a data transformation operation. |
| 9. json-to-xml | DataPower Gateway | DataPower has highly optimized engines for converting between JSON and XML. This is a classic runtime transformation policy. |
| 10. jwt-generate | DataPower Gateway | This policy generates a signed JWT. DataPower has the cryptographic capabilities to create and sign tokens on the fly. |
| 11. xslt | DataPower Gateway | Transforming XML using XSLT is a native, high-performance capability of the DataPower appliance. |
Key Takeaways:
- All the policies listed (1-11) are executed on the IBM DataPower Gateway. This is the “engine” of your API processing pipeline.
- The Developer Portal is a separate service that provides the user interface for developers. Its main jobs are:
- Catalog of available APIs.
- Documentation and interactive API documentation (SwaggerUI).
- User registration and application creation.
- Obtaining API keys and OAuth client IDs/Secrets for use at the gateway.
- Testing APIs through its built-in “Test” feature (which actually sends requests to the gateway).
- The Management Server is another component that handles API design, assembly (using the policy palette), and product packaging, but it also does not execute the runtime policies.
Component Communication Strategy
- Policy Definitions vs. Policy Execution:
- Definition (Design-Time): Policies are defined by XML schema files that tell the API Manager UI what properties to show you when you drag a policy into your assembly. These schemas are part of the API Connect Managementcomponent.
- Execution (Run-Time): The actual code that executes the policy (e.g., the XSLT code for
validate-usernametoken) is deployed to and runs entirely on the DataPower Gateway.
- The Developer Portal’s Role:
The Developer Portal is a consumer-facing web application. Its sole purpose is to:- Display API documentation.
- Let developers sign up, create apps, and get credentials.
- Provide a “Test” button to try APIs.
- It does not store, define, or manage the policies that make up your API logic. It is a client of the system, not part of the core engine.
- How an Upgrade Works in an Air-Gapped Environment:
An upgrade involves pulling new container images or installation packages for the various components (Management, Portal, Gateway) and deploying them.- It’s common to upgrade the Management and Portal components together in a coordinated fashion, as they have interdependencies.
- The Gateway is often on its own upgrade path and can be updated independently.
Why You See Policy Updates After a Management Upgrade
When the API Connect Management component is upgraded, it brings new versions of the policy definition schemas. This means:
- New Features/Bug Fixes: The updated policies likely contain bug fixes, security patches, or new configuration options that IBM has released.
- The “Update” Notification: When you open an existing API assembly in the API Manager UI, it compares the policy version in your saved API definition with the latest version now available from the upgraded Management server. It then flags the policy with an “update available” indicator (often a small arrow or icon). This is purely a design-time notification.
- No Automatic Change to Execution: Crucially, this update notification does not mean the executing code on DataPower has changed yet. The old policy code is still running. The update is only applied to the gateway when you explicitly update the policy in the assembly and then re-deploy the API to the gateway.
No responses yet