Handling responses in EPL

In order to have the response to an HTTP request handled by your EPL application, you need to configure the HTTP server chain correctly and then respond to the event delivered to your application. The transport must have automaticResponses set to false in the configuration (see also Configuring the HTTP server transport), and it must map the following variables into the message to be able to send responses.

This variable is set by the transport for every message. Responses must also have the same metadata.requestId set. This is normally done by mapping it to a payload field in your request for the message sent to the host and then back into the metadata for the response.

This variable is set when creating the chain. This should be set in your request messages. It tells the EPL application to which channel responses should be sent back. Responding messages should also set metadata.http.statusCode correctly.

Note:
You must send the response to the channel specified in the corresponding request event. The channel name is not guaranteed to be constant even within a single manager.

dynamicChains:
HTTPServerChain:
- apama.eventMap:
defaultEventType: RequestEvent
defaultChannel: requests
- mapperCodec:
"*":
towardsHost:
mapFrom:
- payload.requestId: metadata.requestId
defaultValue:
- payload.responseChannel: "@{httpServer.responseChannel}"
towardsTransport:
mapFrom:
- metadata.requestId: payload.requestId
defaultValue:
- metadata.http.statusCode: 200
- jsonCodec
- stringCodec
- HTTPServerTransport:
automaticResponses: false
allowedMethods: [ PUT ]

Your EPL application must then respond to messages, preserving the requestId and responding on the correct channel. For example:

on all RequestEvent() as re {
any data := // do something to get the response data
send ResponseEvent(re.requestId, data) to re.responseChannel;
}

Note:
The request and response events given here are examples. You must define your own events appropriate to your application. For more examples, see Examples.

If a response is not received by the transport within the configured timeout, then the transport returns a 504 Gateway Timeout response. This timeout can be configured with the responseTimeoutMs configuration option (see also Configuring the HTTP server transport).

The response messages must be converted and mapped using the chain configuration to meet the following requirements:

The response payload is a binary message. This will probably be created using the String codec from the event.

The metadata.http.statusCode variable is set. This will usually be set to 200 by the Mapper codec.

The metadata.contentType and metadata.charset variables are set. These will usually be set by the JSON codec and String codecs when in use, but can also be set by the Mapper codec.

In addition, you can set other HTTP headers. For more details, see Mapping events between EPL and HTTP server requests.