Flow action requests

A requests action executes a group of HTTP requests in parallel.

There are two ways to define requests in a requests action:

• Define static requests in the body of the requests element.
• Create a request definition dynamically with XSLT.

A requests element can contain both request types:

• default-request
• request

Request options defined in the sources.xml take effect as usual. They may be augmented or overridden by any additional request options contained in the request element.

The response body for each request will be written into fit://request/content/<ID> where <ID> is the request identifier as specified by the content attribute of the corresponding request element. For the default-request or in case the content attribute is missing, the default content ID main will be used. Each content ID must be unique.

Further information about the response, such as headers and status code can be found in fit://request/content/<ID>/response.

Static request definitions

Static request definitions are included directly in the flow.

A simple example for the definition of parallel requests

To avoid waiting times, we recommend running as many requests in parallel as possible.

<flow>
  ...
  <requests>
    <!-- Response in "fit://request/content/main" -->
    <default-request />
    <!-- Response in "fit://request/content/weather" -->
    <request content="weather" url="http://weather.example.com/forecast" />
  </requests>
  ...
</flow>

A simple example for the definition of a static request

<flow>
  ...
  <requests>
    <request content="example" method="GET" url="http://example.com/">
      <normalize-urls />
      <header name="X-Example" value="Example"/>
    </request>
  </requests>
  ...
</flow>

Dynamic request definitions

Syntax

No child elements.

Attributes:

• xslt="..." location of the XSLT stylesheet (required)
• xslt-cache="..." set to false to disable the XSLT compiler cache (optional, default is true). The XSLT cache requires FIT_XSLT_USE_CACHE setting in fit.ini to be left at the default value, true.

Dynamic request definitions are created at runtime using XSLT. The xslt attribute must contain a link to the XSLT stylesheet that will be used to create the request definition:

<flow>
  ...
  <requests xslt="fit://site/config/requests.xsl" />
  ...
</flow>

The XSL transformation uses fit://request/request as its input DOM, as this location contains all available information about the client’s incoming request including all headers and params. If you need other data sources in your transformation, use the XSLT document function, e.g. document('fit://request/dc').

Creating a dynamic default-request

As mentioned before, all the FIT Server requests to the backend sources are supplemented with the static parameters and options from the sources.xml. You can override any request parameter or option for specific requests with the requests action:

<!-- Example content of the "request.xsl" used by a "requests" action: -->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:template match="/">
    <requests>
      <!-- The default-request enhanced with... -->
      <default-request />

      <!-- ... a dynamic parameter from the Delivery Context -->
      <header name="X-CDR-ID"
              value="{document('fit://request/dc')/dc/client/fit/cdrid}" />
    </requests>
  </xsl:template>
</xsl:stylesheet>

Forging a default-request

You can create a dynamic request definition that loosely resembles the default-request with the following XSLT code:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:template match="/">
    <requests>
      <request url="{/request/@url}">
        <xsl:copy-of select="/request/query"/>
        <xsl:copy-of select="/request/post"/>
        <xsl:copy-of select="/request/upload"/>
        <headers pass="Accept-Language, X-Forwarded-For, If-Modified-Since, If-None-Match" />
      </request>
    </requests>
  </xsl:template>
</xsl:stylesheet>