APIC User Defined Policies

This post will provide an overview of what is the User Defined Policies (UDP) in API Connect.

This topic is part of the information that can be found in the github repository.

The repository provides more details on how to create and package the UDPs.

Introduction

UDP is a user defined policy that is made available as a new policy in the API Connect manager UI and made available on the gateway.

From V2018 DataPower, the API Connect Gateway, has been enhanced with new native objects to address API management capabilities. It is now known as API Gateway and it is made of native DataPower objects.

From V10 two types of User Defined Policies (UDP) are available: the catalog and global scoped UDP.

The difference is described in the KC at Authoring policies:

catalog scoped UDP

The catalog scoped UDP has the following properties:

• Available in the UI for the API developer. To make it available you need to deploy the policy in the sandbox
• Has to be deployed in each catalog where the API using the UDP is published
• made of:
  • prebuilt API Connect policies (invoke, gatewayscript, xslt, …) defined within an assembly (just as a normal API assembly)
  • DataPower processing rule that has been exported
• non default DataPower objects used by the processing rule or Actions have to be created before.

To create this UDP, the user needs to be part of a provider organization and have access to the catalog where the UDP has to be deployed.

global scoped UDP

The global scoped UDP has the following properties:

• Available in the UI for the API developer.
• Available for the whole gateway service (all catalog configured with this gateway service will be able to use it).
• made of any DataPower objects. The objects are created using a configuration file.
• processing rule can be called from a gatewayscript

With this policies, it is possible to provide configuration file containing DataPower commands that are used to create DataPower objects used by the UDP. For example the mq-invoke UDP uses a queue manager object that is created with a configuration file.

From KC:

A configuration sequence is a script-based way to create, modify, and delete configurations on the DataPower® Gateway.

Configuration files can be found in config, local and temporary/config.

To create this UDP, the user needs to be part of the admin organization and have the right to deploy the UDP.

Available functions

Any DataPower capabilities can be used from a UDP:

• XSLT
• GatewayScript
• Processing rules called from an XSLT or Gatewayscript
• Assembly actions

It is good to know that all of these capabilities can be used directly in an assembly as well, the UDP just made a wrapper around the actions that you have defined allowing easy reuse.

DataPower objects can be created along with your assembly UDP when the extension is created (when using the global scope UDP). Like for example in this repository there is the mq-invoke global UDP to access a queue manager. The UDP is packaged with a configuration file that is creating a mq-qm object to connect to a remote queue manager. This queue manager object is then used in the gatewayscript using an url-open.

Processing rules

This section shows how to call a processing rule from a gatewayscript using the multisteplibrary as documented in the KC multistep

var ms = require ('multistep');

var inputMessage = context.createMessage('inputCtx');
inputMessage.body.write('{"myJSONPayload":"MyPayload"}');


// Input of multistep is the name of a message object. And the messageObj.body is the payload
// outputCtx will be a message object containing the response
try {
    ms.callRule ('myRuleName', 'inputCtx', 'outputCtx', 
      function(error) {
          var result = null;

          if (error) {
              //check if output context variable is defined
              if (outputCtx != '') {
                console.info("output context %s", JSON.stringify(outputCtx));
              }
                console.error(error);
                session.output.write(error);
          } else if (outputCtx != '') {
              console.info("writing result %s", result);
              session.output.write(context.get(outputCtx.body));
          }
      }
    );
} catch (error) {
    console.error(error);
    session.output.write(error);
}

var ms = require('multistep');

var fooObj = context.createMessage('foo');
var barObj = context.createMessage('bar');

fooObj.body.write('HelloWorld');
fooObj.header.set('Header1', 'myHeader');
fooObj.setVariable('Var1', 'myVar');

ms.callRule('rule1', 'foo', 'bar', function(error) {
  barObj.body.readAsBuffer(function(error, buf) {
    var OutputPayload = buf.toString();
    var OutputHeaders = barObj.header.get();
    var OutputVar1 = barObj.getVariable('Var2');
  });
});

Resources

This topic is part of the information that can be found in the github repository.