Filter Configurations
The idea behind filter configurations is to create a general filter structure which an author would implement according to the requirements of the target system. The underlying implementation (pfx-api, pxf-rest) would use such a filter and query the target system accordingly.
Limitations
Filter representation is now limited to the HTTP protocol. Within the protocol, the filter may appear in the following parts:
URI (as query params)
HTTP headers
Request body
The location and representation of the filter is defined by author of the configuration scheme.
Definition
Filter configurations are represented in the XML format so that it is easier to work with the transformer function. This is a sample filter configuration:
<filters>
<filter>
<name>sap-body-filter</name> // name of the config, must be unique
<type>body</type> // type of the filter. Might be: body, header, uri, pricefx
<transformer>
<language>groovy</language> // language used for the script below. Supported: groovy, simple, constant
<script> // transformer function definition
def res = [:]
if (!headers['filter-resultFields']?.empty){ res.put('fields', headers['filter-resultFields']) }
if (!headers['filter-sortBy']?.empty){ res.put('sort', headers['filter-sortBy'].join('-')) }
if (headers['filter-condition'] != null){ res.put('condition', headers['filter-condition'].criteria.collect{it -> it.fieldName + it.operator.sign + it.value}.join(',')) }
return res
</script>
</transformer>
</filter>
</filters>
Implementation Notes
script
is subject to Sandboxing – not all features are enabled. For details see Groovy Sandbox.
If the
type
ispricefx
, the filter can only be used in thepfx-api
component. In such case, thetransformer
element is not required. The filter will appear in the request body as JSON.type =
header
– Filter will appear in the request headers.type =
uri
– Filter will appear in the request URL as query parameters.
If the
type
isbody
,header
oruri
, the filter can only be used in thepfx-rest
component. According to the selectedtype
, the filter will appear in:type =
body
– Filter will appear in the request body as JSON.type =
header
– Filter will appear in the request headers.type =
uri
– Filter will appear in the request URL as query parameters.
The
script
section describes the transformer function which is used to transform the general filter structure into a system-specific filter. There are several limitations and notes:The script must be compilable and must always return a value.
The returned data type must be Map.
Available properties within the script are:
Name | Type | Key | Data type |
---|---|---|---|
Result fields | header | headers['filter-resultFields'] | List |
Sort by | header | headers['filter-sortBy'] | List |
Condition | header | headers['filter-condition'] | Object |
Using Languages
You can use language in the <transformer>
tag. Language placeholders will be resolved if the map result values are of the String
type. Supported languages are simple
, constant
and groovy
.
Use the following syntax to enforce use of languages:
$simple{...}
, e.g.$simple{header.salesforceObjectType}
$constant{...}
, e.g.$constant{Customer}
$groovy{...}
, e.g.$groovy{exchange.in.headers.salesforceObjectType}
Example
Focus on:
Using filter configuration with parameters
URI filter
Configuration
<filter>
<name>test-uri-filter-properties</name>
<type>uri</type>
<transformer>
<language>groovy</language>
<script>
[q: 'select ' + headers['filter-resultFields']?.join(',') + ' from $simple{header.salesforceObjectType} and $groovy{exchange.in.headers.salesforceObjectType2} and $constant{Customer} where 1=1 and ' + headers['filter-condition']?.collect{it -> it.criteria[0].fieldName + it.criteria[0].operator.sign + it.criteria[0].value}.join(' and ')]
</script>
</transformer>
</filter>
Filter
new Filter(
resultFields: "id,name,surname",
sortBy: 'id',
condition: new AndCondition(
criteria: [new Restriction("id", Operator.lessThan, 10)]
),
transformerRef: 'test-uri-filter-properties'
)
Route
Result
IntegrationManager version 5.8.0