Processors

This page lists all the processors available in the Mapfish Print distribution. The documentation consists of several parts:

  • Description: the full description for each processor can be found by expanding one of the list elements.
  • Configuration: the configuration options are also listed when a processor element is expanded. A configuration option is a value that can be set on the processor in the configuration yaml file. These options are consistent across all print jobs because they are not provided by the client.
  • Input: the required input values of the processor are listed when the processor element is in expanded form. Input values are either attributes or the output values of other processors.
  • Output: the output values of the processors are also listed when a processor element is expanded. As the name implies, the output values are the data the processor produces and is the input of other processors or the input parameters of the outputFormat template.

A processor's main responsibility is to take the attributes for the print job and producing the parameters required by the output format to produce the report.

While many processors are responsible for directly producing the parameters required by the output format, some processors be considered support processors. A support processor is a processor that in some way prepares attributes for the primary processors. For example, there are processors that can add layers to the map so that all maps will have the layers (reducing the data the client needs to send.) Another example are several processors which configure how http requests are make (add cookies, headers, remap URLs, etc...)

A processor usually has inputs and outputs, in the simple case an input is one of the attributes and the outputs all map to parameters in the Jasper template. Each input and output have default names and often these are sufficient.

However consider the case where a report had two maps (or legends or....). In this case the default input and output parameter names are not sufficient because the input attributes need to be mapped to the correct processor and the output values need to be mapped to the correct parameters in the templates. In order to account for this case, processors have the configuration options: inputMapper and outputMapper.

inputMapper and outputMapper configuration parameters can be configured as follows: 

- !createMap
    inputMapper: {attributeName: defaultInputParamName}
    outputMapper: {defaultOutputName: templateParamName}
Or if the there are multiple mappings that need to be made : 
- processorName
    inputMapper : {
      attributeName1 : inputName1
      attributeName2 : inputName2
    }

!addBackgroundLayers

This processor adds the configured set of layers to the map.

This is useful when all maps should have a default set of background layers or overlays added to those that the client sends for printing.

This can simplify the client so the client only needs to be concerned with the data layers.

See also: !staticLayers attribute

Example

 add_overlay_layer   report 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
position
Set the position enumeration which indicates where the layers should be added to the map: AddStaticLayersProcessor.StaticLayerPosition.
prefix

Inputs

map required
staticLayers required

!addHeaders

This processor allows adding static headers to an http request.

Example: add a Cookie header with multiple header values and add header2 with only one value 

 - !addHeaders
   headers:
     Cookie: [cookie-value, cookie-value2]
     Header2: header2-value

Can be applied conditionally using matchers, like in RestrictUrisProcessor (!restrictUris ).

Example

 http_processors 

Configuration

headers
inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
matchers
The matchers used to select the urls that are going to be modified by the processor. For example: 
 - !restrictUris
   matchers:
     - !localMatch
       dummy: true
     - !ipMatch
     ip: www.camptocamp.org
     - !dnsMatch
       host: mapfish-geoportal.demo-camptocamp.com
       port: 80
     - !dnsMatch
       host: labs.metacarta.com
       port: 80
     - !dnsMatch
       host: terraservice.net
       port: 80
     - !dnsMatch
       host: tile.openstreetmap.org
       port: 80
     - !dnsMatch
       host: www.geocat.ch
       port: 80
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required

!addOverlayLayers

This processor adds the configured set of layers to the map.

This is useful when all maps should have a default set of background layers or overlays added to those that the client sends for printing.

This can simplify the client so the client only needs to be concerned with the data layers.

See also: !staticLayers attribute

Example

 add_overlay_layer   report 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
position
Set the position enumeration which indicates where the layers should be added to the map: AddStaticLayersProcessor.StaticLayerPosition.
prefix

Inputs

map required
staticLayers required

!configureHttpRequests

A processor that wraps several AbstractClientHttpRequestFactoryProcessors.

This makes it more convenient to configure multiple processors that modify MfClientHttpRequestFactory objects.

Consider the case where you need to:

  • Restrict allowed URIS using the !restrictUris processor
  • Forward all headers from print request to all requests using !forwardHeaders
  • Change the url using the !mapUri processor

In this case the !mapUri processor must execute before the !restrictUris processor but it is difficult to enforce this, the inputMapping and outputMapping must be carefully designed in order to do it. The following should work but compare it with the example below: 

 - !mapUri
   mapping:
     (http)://localhost(.*): "$1://127.0.0.1$2"
   outputMapper: {clientHttpRequestFactoryProvider: clientHttpRequestFactoryMapped}
 - !forwardHeaders
   all: true
   inputMapper: {clientHttpRequestFactoryMapped :clientHttpRequestFactoryProvider}
   outputMapper: {clientHttpRequestFactoryProvider: clientHttpRequestFactoryWithHeaders}
 - !restrictUris
   matchers: [!localMatch {}]
   inputMapper: {clientHttpRequestFactoryWithHeaders:clientHttpRequestFactoryProvider}

The recommended way to write the above configuration is as follows: 

 - !configureHttpRequests
   httpProcessors:
     - !mapUri
       mapping:
         (http)://localhost(.*): "$1://127.0.0.1$2"
     - !forwardHeaders
       all: true
     - !restrictUris
       matchers: [!localMatch {}]

Example

 http_processors 

Configuration

httpProcessors
inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required
values required

!createDataSource

A processor that will process a DataSourceAttribute.DataSourceAttributeValue and construct a single Jasper DataSource from the input values in the DataSourceAttribute.DataSourceAttributeValue input object.

The DataSourceAttribute.DataSourceAttributeValue has an array of maps, each map in the array equates to a row in the Jasper DataSource.

The DataSourceProcessor can be configured with processors that will be used to transform each map in the input array before constructing the final DataSource row.

For example, each map in the array could be MapAttribute.MapAttributeValues and the DataSourceProcessor could be configured with !createMap processor. In this scenario each element in the array would be transformed by the !createMap processor and thus each row of the resulting DataSource will contain the map subreport created by the !createMap processor.

An additional point to remember is that (as with the normal execution) in addition to the output of the processors, the attributes in the input map will also be columns in the row. This means that the jasper report that makes use of the resulting DataSource will have access to both the results of the processor as well as the input values (unless overwritten by the processor output).

If the reportKey is defined (and reportTemplate) then a the reportTemplate jrxml file will be compiled (as required by all jrxml files) and an additional column will be added to each row [reportKey] : [compiled reportTemplate File]

If reportKey is defined the reportTemplate must also be defined (and vice-versa).

See also: !datasource attribute [[examples=verboseExample,datasource_dynamic_tables,datasource_many_dynamictables_legend, datasource_multiple_maps,customDynamicReport,report]]

Configuration

attributes
copyAttributes
inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix
processors
All the processors that will executed for each value retrieved from the Values object with the datasource name. All output values from the processor graph will be the datasource values.

Each value retrieved from values with the datasource name will be the input of the processor graph and all the output values for that execution will be the values of a single row in the datasource. The Jasper template can use any of the values in its detail band.

reportKey
The key/name to use when putting the path to the compiled subreport in each row of the datasource. This is required if reportTemplate has been set. The path to the compiled subreport will be added to each row in the datasource with this value as the key. This allows the containing report to reference the subreport in each row.
reportTemplate
The path to the report template used to render each row of the data. This is only required if a subreport needs to be compiled and is referenced in the containing report's detail section.

The path should be relative to the configuration directory

Inputs

datasource required
template required
values required

Outputs

jrDataSource required

!createMap

A processor to render a map that can be embedded as a sub-report into a JasperReports template.

See also: !map attribute

Example

 verboseExample 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required
map required
outputFormat
tempTaskDirectory required
template required

Outputs

layerGraphics required
mapContext required
mapSubReport required

!createMapPages

Processor used to display a map on multiple pages.

This processor will take the defined map attribute and using the geometry defined in the map attribute's area of interest, will create an Iterable each of which contains:

  • a new definition of a map attribute
  • name value which is a string that roughly describes which part of the main map this sub-map is
  • left value which is the name of the sub-map to the left of the current map
  • right value which is the name of the sub-map to the right of the current map
  • top value which is the name of the sub-map to the top of the current map
  • bottom value which is the name of the sub-map to the bottom of the current map

It will also create a paging overview layer for the main map if you have set renderPagingOverview to true in !paging attribute

The iterable of values can be consumed by a !createDataSource processor and as a result be put in the report (or one of the sub-reports) table. One must be careful as this can result in truly giant reports.

See also: !paging attribute

Example

 paging   paging_with_overview_layer 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

map required
paging required

Outputs

datasource required

!createNorthArrow

Processor to create a north-arrow for a map.

The north-arrow is rotated according to the rotation of the associated map.

Example configuration: 

 attributes:
   ...
   northArrow: !northArrow
     size: 50
     default:
       graphic: "file://NorthArrow_10.svg"

 processors:
 ...
   - !createNorthArrow {}

See also: !northArrow attribute

Example

 verboseExample   print_osm_new_york_nosubreports 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required
map required
northArrow required
tempTaskDirectory required
template required

Outputs

northArrowGraphic required
northArrowSubReport required

!createOverviewMap

Processor to create overview maps. Internally CreateMapProcessor is used.

Example Configuration: 

 attributes:
    ...
    overviewMap: !overviewMap
      width: 300
      height: 200
      maxDpi: 400
 processors:
    ...
    - !createOverviewMap
      outputMapper:
        layerGraphics: overviewMapLayerGraphics
Features:

The attribute overviewMap allows to overwrite all properties of the main map, for example to use different layers. The overview map can have a different rotation than the main map. For example the main map is rotated and the overview map faces north. But the overview map can also be rotated.

The style of the bbox rectangle can be changed by setting the style property.

See also: !overviewMap attribute

Example

 verboseExample   overviewmap_tyger_ny_EPSG_3857 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required
map required
outputFormat
overviewMap required
tempTaskDirectory required
template required

Outputs

layerGraphics required
overviewMapSubReport required

!createScalebar

Processor to create a scalebar for a map.

See also: !scalebar attribute

Example

 verboseExample   print_osm_new_york_EPSG_3857   print_osm_new_york_nosubreports 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

mapContext required
scalebar required
tempTaskDirectory required
template required

Outputs

scalebarGraphic required
scalebarSubReport required

!dateFormat

A processor that creates a date formatter that can be used in Jasper.

Example Configuration: 

 attributes:
   ...
   timezone: !string
     default: PST
 processors:
   ...
   - !dateFormat
     pattern: "EEEEE dd MMMMM yyyy HH:mm"

Will take into account the "lang" field, if passed in the request: 

 {
   "lang": "fr_CH",
   "attributes": {
      ...
      "timezone": "CET"
   },
   ...
 }

In your template, you can use it like that: 

 
   
   ...
   
     ...
     $P{dateFormat}.format(TODAY())

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
pattern
The pattern to use to format dates.

See https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html

prefix

Inputs

REPORT_LOCALE required
timezone
The timezone to use.

Either an abbreviation such as "CET", a full name such as "Europe/Zurich", or a custom ID such as "GMT-8:00". Defaults to the OS timezone.

Outputs

dateFormat required

!forwardHeaders

This processor forwards all the headers from the print request (from the Mapfish Print client) to each http request made for the particular print job. All headers can be forwarded (if forwardAll is set to true) or the specific headers to forward can be specified.

Example 1: Forward all headers from print request 

 - !forwardHeaders
   all: true

Example 2: Forward specific headers (header1 and header2 will be forwarded) 

 - !forwardHeaders
   headers: [header1, header2]

Can be applied conditionally using matchers, like in RestrictUrisProcessor (!restrictUris ).

Example

 http_processors 

Configuration

all
headers
inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
matchers
The matchers used to select the urls that are going to be modified by the processor. For example: 
 - !restrictUris
   matchers:
     - !localMatch
       dummy: true
     - !ipMatch
     ip: www.camptocamp.org
     - !dnsMatch
       host: mapfish-geoportal.demo-camptocamp.com
       port: 80
     - !dnsMatch
       host: labs.metacarta.com
       port: 80
     - !dnsMatch
       host: terraservice.net
       port: 80
     - !dnsMatch
       host: tile.openstreetmap.org
       port: 80
     - !dnsMatch
       host: www.geocat.ch
       port: 80
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required
requestHeaders required

!mapUri

This processor maps uris submitted to the MfClientHttpRequestFactory to a modified uri as specified by the mapping parameter.

Example: change the hostname of all requests that are http requests and have the hostname: myhost.com to localhost instead of myhost.com 

 - !mapUri
   mapping: {(http)://myhost.com(.*): "$1://localhost$2"}

Can be applied conditionally using matchers, like in RestrictUrisProcessor (!restrictUris ).

Example

 http_processors 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
mapping
Set the uri mappings.

The key is a regular expression that must match uri's string form. The value will be used for the replacement.

matchers
The matchers used to select the urls that are going to be modified by the processor. For example: 
 - !restrictUris
   matchers:
     - !localMatch
       dummy: true
     - !ipMatch
     ip: www.camptocamp.org
     - !dnsMatch
       host: mapfish-geoportal.demo-camptocamp.com
       port: 80
     - !dnsMatch
       host: labs.metacarta.com
       port: 80
     - !dnsMatch
       host: terraservice.net
       port: 80
     - !dnsMatch
       host: tile.openstreetmap.org
       port: 80
     - !dnsMatch
       host: www.geocat.ch
       port: 80
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required

!mergeDataSources

This processor combines DataSources and individual processor outputs (or attribute values) into a single DataSource which can be used in a jasper report's detail section.

An example use case is where we might have zero or many of tables and zero or many legends. You can configure the template with a detail section that contains a subreport, the name of which is a field in the DataSources and the DataSources for the sub-template another field. Then you can merge the legend and the tables into a single DataSources. This way the report will nicely expand depending on if you have a legend and how many tables you have in your report.

Example

 merged_datasource 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix
sources
The source to add to the merged DataSource.

Each source indicates if it should be treated as a datasource or as a single item to add to the merged DataSource. If the source indicates that it is a MergeDataSourceProcessor.SourceType.DATASOURCE the object each row in the datasource will be used to form a row in the merged DataSource. If the source type is MergeDataSourceProcessor.SourceType.SINGLE the object will be a single row even if it is in fact a DataSource.

See also: !mergeSource

Inputs

values required

Outputs

mergedDataSource required

!prepareLegend

Create a legend.

See also: !legend attribute

Example

 verboseExample   legend_cropped   legend_scaled 

Configuration

dpi
inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
maxWidth
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix
scaled
template

Inputs

clientHttpRequestFactoryProvider required
legend required
tempTaskDirectory required
template required

Outputs

legendDataSource required
legendSubReport required
numberOfLegendRows required

!prepareTable

A processor for generating a table.

See also: !table attribute

Example

 verboseExample   datasource_dynamic_tables   customDynamicReport 

Configuration

columns
Set strategies for converting the textual representation of each column to some other object (image, other text, etc...).

Note: The type returned by the column converter must match the type in the jasper template.

converters
Set strategies for converting the textual representation of each cell to some other object (image, other text, etc...).

This is similar to the converters specified for a particular column. The difference is that these converters are applied to every cell of the table (except for the cells of those columns that are assigned a specific converter).

detailStyle
The id of the style to apply to the all columns in the table detail section except first and last columns. This value is will be used as a default if either firstDetailStyle or lastDetailStyle is not defined. This is required if dynamic is true and is not permitted if dynamic is false.

The style must be a style element in the jasperTemplate.

dynamic
If true then the JasperReport template will be generated dynamically based on the columns in the table attribute.

Default: false

excludeColumns
firstDetailStyle
The id of the style to apply to the first column in the table detail section. This is optional.

The style must be a style element in the jasperTemplate.

firstHeaderStyle
The id of the style to apply to the first column in the table header. This is optional.

The style must be a style element in the jasperTemplate.

headerStyle
The id of the style to apply to the all columns in the table header except first and last columns. This value is will be used as a default if either firstHeaderStyle or lastHeaderStyle is not defined. This is required if dynamic is true and is not permitted if dynamic is false.

The style must be a style element in the jasperTemplate.

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
jasperTemplate
The path to the JasperReports template that contains the template for the sub-report. If dynamic is false then the template will be used without any changes. It will simply be compiled and used as is.

If dynamic is true then the template will be used to obtain the column styles and the size of the subreport and to get the position of the first header and field element. The actual field and column definitions will be dynamically generated from the table data that is provided. This may be null if dynamic is false. If it is null then the main template will likely use the generated table datasource directly as its datasource for use in its detail section and the table will be directly in the main template's detail section. Or a later processor may use the table's datasource in someway.

lastDetailStyle
The id of the style to apply to the last column in the table detail section. This is optional.

The style must be a style element in the jasperTemplate.

lastHeaderStyle
The id of the style to apply to the last column in the table header. This is optional.

The style must be a style element in the jasperTemplate.

maxColumns
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix
reportWidth

Inputs

clientHttpRequestFactoryProvider required
table required
tempTaskDirectory required
template required

Outputs

numberOfTableRows required
tableDataSource required
tableSubReport required

!reportBuilder

A processor that actually compiles a JasperReport template file.

Example 

     processors:
         - !reportBuilder # compile all reports in current directory
               directory: '.'

Example

 verboseExample 

Configuration

configuration
Description copied from interface: HasConfiguration
directory
inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

!restrictUris

This processor check urls against a set of url matchers to see if the request should be allowed or rejected.

Usage of processor is as follows: 

 - !restrictUris
   matchers:
     - !localMatch {}
     - !ipMatch
       ip: www.camptocamp.org
     - !dnsMatch
       host: mapfish-geoportal.demo-camptocamp.com
       port: 80
     - !dnsMatch
       host: labs.metacarta.com
       port: 80
     - !dnsMatch
       host: terraservice.net
       port: 80
     - !dnsMatch
       host: tile.openstreetmap.org
       port: 80
     - !dnsMatch
       host: www.geocat.ch
       port: 80

By default a matcher allows the URL, but it can be setup to reject the URL (by setting reject to true). The first matcher that matches will be the one picking the final outcome. If no matcher matches, the URI is rejected. So, for example, you can allow every URLs apart from the internal URLs like that: 

 - !restrictUris
   matchers:
     - !ipMatch
       ip: 192.178.0.0
       mask: 255.255.0.0
       reject: true
     - !acceptAll

If the Print service is in your DMZ and needs to allow access to any WMS server, it is strongly recommended to have a configuration like the previous one in order to avoid having the Print service being used as a proxy to access your internal servers.

Note: if this class is part of a CompositeClientHttpRequestFactoryProcessor (!configureHttpRequests) then it should be the last one so that the checks are done after all changes to the URIs

Example

 http_processors 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
matchers
The matchers used to select the urls that are going to be modified by the processor. For example: 
 - !restrictUris
   matchers:
     - !localMatch
       dummy: true
     - !ipMatch
     ip: www.camptocamp.org
     - !dnsMatch
       host: mapfish-geoportal.demo-camptocamp.com
       port: 80
     - !dnsMatch
       host: labs.metacarta.com
       port: 80
     - !dnsMatch
       host: terraservice.net
       port: 80
     - !dnsMatch
       host: tile.openstreetmap.org
       port: 80
     - !dnsMatch
       host: www.geocat.ch
       port: 80
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required

!setFeatures

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required
features required
map required

!setStyle

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix

Inputs

clientHttpRequestFactoryProvider required
map required
style required
template required

!setTiledWms

Processor that transforms WMS layers that are too big into tiled WMS layers.

This processor will reduce the given max tile size to best match the dimensions of the map. This is to reduce the amount of extra data that is fetched from the WMS server.

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
matchers
The matchers used to select the WMS urls that are going to be modified by the processor. For example: 
 - !restrictUris
   matchers:
     - !dnsMatch
       host: labs.metacarta.com
       port: 80
maxHeight
maxWidth
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix
tileBufferHeight
tileBufferWidth

Inputs

map required

!setWmsCustomParam

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
paramName
prefix

Inputs

map required
value required

!updatePdfConfig

This processor allows the dynamic configuration of the PDFConfig object by obtaining data from attributes. For example the title and author could be string attributes posted from the client, this processor would update the PDFConfig object with the attribute data allowing per report PDF metadata.

Note: The PDFConfig can also be configured in the config.yaml either at the config or template level.

See also: !updatePdfConfigUpdate attribute

Example

 updatePdfMetadata 

Configuration

inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
prefix
updates
The pdf metadata property -> attribute name map. The keys must be one of the values in PDFConfig and the values must be the name of the attribute to obtain the the data from. Example Configuration: 
 processors:
   - !updatePdfConfig
     updates:
       title: "titleAttribute"
       subject: "subjectAttribute"
The type of the attribute must be of the correct type, for example title mus be a string, keywords must be an array of strings, compress must be a boolean.

If the value is within the attribute output object then you can use dot separators for each level. For example suppose there is a custom attribute: myconfig, if and it has a property title then the configuration would be: 

 processors:
   - updatePdfConfig
     updates: {title: :myconfig.title"}
For more power a "format" can be defined. The format is a printf style format string which will be called with a single value that is identified by the value key/path. In this case the short hand key: value can't be used instead it is as follows: 
   - updatePdfConfig
     updates:
       title: !updatePdfConfigUpdate
          valueKey: "myconfig.title"
          format: "Print Report %s"

Inputs

pdfConfig required
values required

!useHttpForHttps

This processor maps https requests to http requests for certain hosts. The port number can also be mapped since that is usually required.

Example: 

 - !useHttpForHttps
   hosts: [localhost, www.camptocamp.com]
   portMapping:
     443: 80
     8443: 8080

Can be applied conditionally using matchers, like in RestrictUrisProcessor (!restrictUris ).

Example

 http_processors 

Configuration

hosts
Set the patterns to use for selecting the hosts to apply the https -> http mapping to.
  • If the host starts and ends with / then it is compiled as a regular expression
  • Otherwise the hosts must exactly match
inputMapper
The input mapper. See "Processors" to know more. Example: 
 inputMapper: {attributeName: defaultInputParamName}
inputPrefix
matchers
The matchers used to select the urls that are going to be modified by the processor. For example: 
 - !restrictUris
   matchers:
     - !localMatch
       dummy: true
     - !ipMatch
     ip: www.camptocamp.org
     - !dnsMatch
       host: mapfish-geoportal.demo-camptocamp.com
       port: 80
     - !dnsMatch
       host: labs.metacarta.com
       port: 80
     - !dnsMatch
       host: terraservice.net
       port: 80
     - !dnsMatch
       host: tile.openstreetmap.org
       port: 80
     - !dnsMatch
       host: www.geocat.ch
       port: 80
outputMapper
The output mapper. See "Processors" to know more. Example: 
 outputMapper: {defaultOutputName: templateParamName}
outputPrefix
portMapping
prefix

Inputs

clientHttpRequestFactoryProvider required