The assembly editor
The API Manager of IBM® API Connect features a graphical editor that you can use to create assemblies. With assemblies, you can readily tailor your APIs to include elements such as activity logging and redaction of specific fields.
- This task relates to configuring an OpenAPI 3.0 API definition. For details on how to configure an OpenAPI 2.0 API definition, see Editing an OpenAPI 2.0 API definition.
- OpenAPI 3.0 APIs are supported only with the DataPower® API Gateway, not with the DataPower Gateway (v5 compatible).
- For details of current OpenAPI 3.0 support limitations, see OpenAPI 3.0 support in IBM API Connect.
You can access the Assemble view by clicking the Gateway view in the API editor. This view includes a palette, which lists the available elements, a property sheet, which is used to configure an element, and a canvas, which is used to arrange and visualize the assembly’s elements.
The palette is a list of different elements that you can include in your assembly. The palette can be hidden by clicking the Show/hide policy palette icon .
You can use the canvas to create a graphical representation of the assembly flow. You can drag various elements from the palette to the appropriate location on the canvas. When you drag an element, valid positions are shown by dashed boxes.
API calls are made at the initial, unfilled, circle, and returned at the final, filled, circle. You can insert elements between the two circles to modify the data received from the call, or returned by the response. To add an element, select it in the palette and drag it across to one of the dashed boxes that appear when you move the element over the canvas.
You can use the Show catches toggle to show and hide error catches in the palette. A catch is a section of the assembly that is applied when an API call results in the corresponding HTTP status code being returned. Click the catch section to open the property sheet for all your catches.
You can zoom the view of your canvas in and out by clicking the + and - icons. To fit the canvas to the screen size, click the Fit to screen icon .
You can filter the canvas to show only the parts of it that will apply to a specific operation by clicking the Filter by operation icon and then selecting the operation from the drop-down list. Click the Clear operation filter icon to remove the filter.
The property sheet
When you select an element that is in the assembly by clicking it, details about the element are displayed in the property sheet. In this pane, you can configure the element's properties. The options available to you in the property sheet are specific to the type of element you are working with. For some elements, you can add and remove properties by clicking Object Properties and selecting the property from the drop-down menu.
You can release the property sheet by clicking the Close icon .
The behavior of an assembly
The assembly runs policies in order and acts on different contexts of the API call. When an API call is made, security and rate limits are enforced before the assembly is executed. During the assembly, the flow can branch or be thrown and caught, according to the policies contained in it. The message context can be thought to flow through the assembly, being used and altered by various policies. In addition to the message, other contexts can be accessed and created.
- Security and rate limiting
- Before the assembly is executed, security and then rate limits are enforced.
First, security definitions and CORS access control are used to authenticate an API call. Any API Key security definitions are used to identify applications that have subscriptions to a Product containing the API. If a security definition does not allow access, the API call is rejected.
If an application is identified by its client ID or client secret, a rate limit can be enforced based on the Plan or operation called.
- The assembly execution sequence
- The assembly is executed in order from the initial, filled, circle to the final, unfilled,
circle. However, there is room for branching, when if and operation-switch logic constructs are
used, or for the remaining assembly to be ignored when a throw policy is executed.
The message is the context that is acted upon by any policy that isn't otherwise configured. At the beginning of the API call, the message is empty and, at the end of the API call, the message is used as the response.
The request context contains the information that is sent by the API caller and varies with the type of operation called and the configuration of that operation. For example, a GET operation can never have a populated
request.body, and you can configure an operation to have
request.parameters(query parameters). The first policy in an assembly acts on the request and produces the first instance of the message. If there are no policies, the request is returned to the caller.
- Managing contexts
- Because the message can be overwritten, it can be useful to create and reference new contexts
where possible so that they are saved and reusable during the API call.
- Use the map policy to overwrite the message context when you need to execute a policy that only acts on the message.
- Use the request context when you want to use the original request made to the API.
- Use the map, invoke, and proxy policies to create new contexts when you want to save your
message. Note: When you create a new context, unless you are also mapping to the message, the message is overwritten with an empty object.
For example, an invoke policy is the first policy in the assembly and its response overwrites the request as the message. The message is then acted upon by a validate policy, and a map policy then saves the message as a new context, ready for a second invoke policy to overwrite the message without losing the first invoke policy's output.
You can also access contexts outside of the message or your custom contexts, but these cannot be written to. For a list of contexts, see API Connect context variables.
- Branches and catches
- Using logic constructs, such as operation-switch or if, you can execute different sections of
the assembly when certain conditions are fulfilled. When the assembly branches, the subsection of
the assembly contained by the construct is executed in the same manner as a complete assembly.
However, contexts are shared with the complete assembly.
When a catch is triggered, either by an error occurring during the execution of a policy, or because a throw policy is encountered, the rest of the assembly flow is ignored. All contexts are shared by the catch being executed and when the end of the catch is reached, the API call is completed. There is no way to return from a catch to the rest of the assembly.