While configuring the various actions (sign, transform, etc.), you may have noticed that each action declares an input and an output context. In the case of a transform action, the input context will be the document that is fed to the transformer, and the results of the transformation will be written to the output context.
Some actions may only have an input context. For example, the verify action has an input context, but no output context; the signature verification either passes or fails. In contrast, some actions may only have an output context. The fetch action can fetch an XML document from a local file or a remote server, and the fetched document becomes the output context.
Contexts are referred to by the following names:
● INPUT – represents the original message as it arrived from the client.
● OUTPUT – represents the outbound message which will be forwarded to the destination. In the case of client-to-server processing, the OUTPUT context represents what will be sent to the backend server. In the case of server-to-client processing, the OUTPUT context represents what will be returned to the client.
● NULL – indicates that the output is not needed. In other words, the output from the action is sent to the bit bucket.
● PIPE – indicates that the output of the action should be piped into the input of the next action. In this case, the input context of the next action must also specify PIPE.
● Named context – in this case, you can assign a name to a context and use it at a later point in the processing rule. For example, a transform action can be configured with an input context of INPUT and an output context of newRequest. Later in the processing rule, another action can use newRequest as the input context.
No comments:
Post a Comment