Using the response from a Custom Extension

[Theodore_Ezell1 (Theo Ezell)]

*products versions - webMethods API Gateway version: 10.7 and above

Introduction

This article shows how to access the results of a Custom Extension by creating custom variables and populating them with the results of calling a webMethods.io Integration service. While this example uses a Request Processing policy, the same technique applies to any policy which calls a Custom Extension.

Sample use case

When using Custom Extensions in API policies, it is a common requirement to access the returned data values. If the call returns an HTTP error, it is also often required to access the returned code and/or status message. This example will use a Request Transformation policy Custom Extension to look up the internal partner ID for the provided external partner ID. If the internal partner ID is not found, then the extension service will return an error message, which will be returned to the API consumer. If successful, this example returns the internal partner ID in the response header, just to demonstrate how to access the result.

Pre-requisites for example

Integration service to call as Custom Extension – This can be any endpoint on any runtime. This example uses a Flow Service hosted in webMethods.io Integration, that has been configured to enable HTTP invocation.

Aliases for service endpoint & authentication – While not a technical requirement, it is often useful to create aliases for environment-specific values. In this case, there are 2 aliases, Custom_Extension_EndPoint_Alias, for the endpoint URL, and Custom_Extension_Auth_Alias, containing the value for the Authorization header.

Steps to follow

1. Edit the API and add Request Processing > Custom Extension policy.
   

   

2. Configure the policy to use the endpoint alias: ${Custom_Extension_EndPoint_Alias}
   

   

3. Configure the extension policy to pass any required data and/or authentication. In this case, we have added 2 headers:
   ext-partner-id: ${request.headers.ext-partner-id}
   Authorization: ${Custom_Extension_Auth_Alias}
   

   

4. Under Response Processing, configure the desired exception behavior and add custom variables for the returned data. In this case, if there is an exception, we want to return the error message returned by the extension to the API consumer. If the service succeeds, then it returns a simple JSON in the payload, so we extract it using a simple JSON query.
   ${error}: ${response[customExtension].payload}
   ${code}: ${response[customExtension].statusCode}|
   ${response[customExtension].payload.jsonPath[$.int-partner-id]}
   

   

5. Add a Response Processing > Response Transformation policy to return the data returned by the Custom Extension. Here, we are passing the result of the lookup in a custom header.
   ${response.headers.int-partner-id}: ${int-partner-id}
   

   

6. Lastly, we add an Error Handling > Conditional Error Processing policy to return the error message from the Custom Extension if the lookup fails.
   

   

Testing the Custom Extension

Now, we are ready to test. Valid values for the ext-partner-id in this example are P001, P002 and P003. Sending in a valid id returns the appropriate int-partner-id.

If an invalid ext-partner-id code is sent, then the API returns the error from the Custom Extension in the payload.

Next steps

If you would like to learn more about using Custom Extensions, our YouTube channel has a short video tutorial. If you haven’t already, sign up for a fully functional free trial. See for yourself why Software AG has been named a Leader in the 2022 Gartner® Magic Quadrant™ for Full Life Cycle API Management for the fifth consecutive year.