rest-compatible methods | Pricefx Knowledge Base

Following methods can be used:

get
post
put
delete
head
options
trace
patch

All methods are transcript for an actual call. For example, pfx-rest:get will eventually call GET https://test.me/...

Properties

The table below lists URI parameters you can set on a single pfx-rest:method endpoint. The HTTP transport options in the table (timeouts, connection pooling, keep-alive, proxy) are also configurable as process-wide defaults via integration.pfx-rest.* properties in application.properties. A URI parameter overrides the matching default for that one endpoint; if you don't set it, the global default applies.

Applicability — these parameters configure the pfx-rest Camel component, which is used to call non-PriceFx REST APIs (SAP, Salesforce, custom HTTP services, etc.). They do not affect PriceFx partition calls — those go through the pfx-api component, which uses the pricefx-client library and is tuned by a separate integration.pfx.* namespace.

Option	Type	Since Version	Default	Description
`uri`	string			URI to fetch data from. If the parameter `url` is specified on the connection, only the resource path must be provided (e.g. /v2/accounts). If the parameter `url` is not specified on the connection, the full path must be provided (https://...). If there are parameters needed in URI, each parameter should be placed as a placeholder `%s`.
`connectionTimeoutMs`	integer		20000	Legacy connection timeout (ms). Kept for backwards compatibility — prefer `connectTimeoutMs`. Used both for the authentication request and the fetch. Global default: `integration.pfx-rest.connection-timeout-ms`.
`maxResponseSizeInMB`	integer		0	Defines maximum size of a response in MB. After reaching the limit, an exception will be thrown. If the default value (0) is set, the response size is not checked.
`contentType`	string		application/json	Content type of the fetch request. The value has to follow the HTTP standard.
`okStatusCodeRange`	string		200-299	Status codes which are considered a success response. The values are inclusive. Multiple ranges can be defined, separated by a comma, e.g. 200-204,209,301-304. Each range must be a single number or from-to with the dash included.
`proxyHost`	string			Proxy host. Must be set together with `proxyPort`. Global default: `integration.pfx-rest.proxy-host`.
`proxyPort`	integer			Proxy port. Must be set together with `proxyHost`. Global default: `integration.pfx-rest.proxy-port`.
`connection`	string			Name of an existing connection which will be used to access the resource.
`autoDecode`	Boolean		true	Indicates that encoded data (gzip, deflate, ...) should be automatically decoded.
`failIfNoConnection`	Boolean		false	Determines whether to fail if a connection is missing or whether to use the default connection.
`disableStreamCache`	Boolean		false	If set to true, the content is streamed directly to a file. Otherwise the content is stored to the memory. File location can be set using the `downloadDir` option.
`fileKey`	string		file	If a multipart file is uploaded, specifies a key of the file.
`useBoundary`	Boolean		true	If a multipart file is uploaded, determines whether to use boundary in the request body and content type.
`inputSource`	string	4.7.0		Defines input source for data in exchange. It can be stored in the header, property or body.
`inputSourceName`	string	4.7.0		Defines input source name for the source type header and property. Put here the name of the exchange header or exchange property.
`outputTarget`	string	4.7.0		Defines output target for data in exchange. It can be stored in the header, property or body.
`outputTargetName`	string	4.7.0		Defines output target name for the target type header and property. Put here the name of the exchange header or exchange property.
`downloadDir`	string	4.9.0		If `disableStreamCache` is set to `true`, this option can be used to set a custom temporary file directory location (for example to make sure the location is accessible from the route).
`responseTimeoutMs`	long	6.2.0	20000	Time (ms) the client waits for the response headers after the request is sent. Global default: `integration.pfx-rest.response-timeout-ms`.
`connectTimeoutMs`	long	6.2.0	20000	Time (ms) to establish the TCP connection to the target host (fires before the request is sent). Global default: `integration.pfx-rest.connect-timeout-ms`.
`reuseConnection`	boolean	6.2.0	true	Reuse pooled keep-alive connections across requests to the same target. Set to `false` to open a fresh connection per request. Global default: `integration.pfx-rest.reuse-connections`.
`useMinimalKeepAliveStrategy`	boolean	6.2.0	false	When `true`, ignore server-advertised `Keep-Alive` and use a minimal duration. Useful behind load balancers that close idle connections aggressively; effectively disables connection reuse. Global default: `integration.pfx-rest.use-minimal-keep-alive-strategy`.
`evictExpiredConnections`	boolean	6.2.0	true	Run a background evictor that removes pooled connections that exceeded their keep-alive lifetime. Global default: `integration.pfx-rest.evict-expired-connections`.
`evictIdleConnections`	boolean	6.2.0	true	Run a background evictor for connections idle longer than `evictIdleConnectionsMaxIdleTimeMs`. Independent from `evictExpiredConnections`. Global default: `integration.pfx-rest.evict-idle-connections`.
`evictIdleConnectionsMaxIdleTimeMs`	long	6.2.0	30000	Idle timeout (ms) used by `evictIdleConnections` to close idle connections. Global default: `integration.pfx-rest.evict-idle-connections-max-idle-time-ms`.
`maxConnectionsTotal`	integer	6.2.0	200	Maximum total HTTP connections kept in the pool across all routes. Global default: `integration.pfx-rest.max-connections-total`.
`maxConnectionsPerRoute`	integer	6.2.0	100	Maximum concurrent HTTP connections per target route (host/port pair). Global default: `integration.pfx-rest.max-connections-per-route`.
`soKeepAlive`	boolean	6.2.0	true	Enable the SO_KEEPALIVE socket option so the OS pings idle TCP connections to detect half-closed peers. Global default: `integration.pfx-rest.so-keep-alive`.
`soTimeoutMs`	long	6.2.0	3_600_000	Socket read timeout (ms) once the response body is streaming. Higher than `responseTimeoutMs` because slow downloads can be normal. Global default: `integration.pfx-rest.so-timeout-ms`.

Unknown Properties

Unknown properties are handled as query parameters. For details see the section below.

An exception is when using the method pfx-rest:system – in this case, unknown properties are handled as properties.

Input Source / Output Target

A standard way to put data to a component or retrieve them from a component is using body. However, in certain cases it is not the best option. Hence the inputSource, inputSourceName, outputTarget and outputTargetName properties were created to tackle the problem.

An example how to define a component that fetches data from the header header1:

XML

<to uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&amp;inputSource=header&amp;inputSourceName=header1"/>

Example how to populate data from the body:

XML

<setBody>
  <constant>body123</constant>
</setBody>  
<to uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data"/>

Body is default option. You can also set inputSource=body, the effect would be the same.

Example how to send results to the property prop1:

XML

<to uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&amp;outputTarget=property&amp;outputTargetName=prop1"/>

The toD Problem

The toD option might seem more dynamic:

XML

<setHeader name="MyCustomMap">
  <constant>{"somedata":"exactly as endpoint expects"}</constant>
</setHeader>
<toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&amp;payload=\${headers.MyCustomMap}"/>

However, this option has a caveat described here. In short, using toD interpolates the parameters, so the result component is:

XML

<toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&amp;payload={"somedata":"exactly as endpoint expects"}"/>

When you change the data in the header MyCustomMap to data2, this component would be created:

XML

<toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&amp;payload=data2"/>

So if the parameter has variable content (let's say n), there would be n components and endpoints created, which would negatively affect performance.

In this case, if you use static parameters with <to....inputSource=header&inputSourceName=head1, only one component and one endpoint would be created for all possible values, offering top performance.

Handling ZIP Response

If an endpoint returns a ZIP response (content-type=application/zip) and the disableStreamCache option is set to false, then the response will be stored into memory as a Base64 encoded string. This allows you to work with the ZIP file in a route.

Examples

Call with payload from header

XML

<route>
  <from uri="direct:start"/>
  <setHeader name="MyCustomMap">
    <constant>{"somedata":"exactly as endpoint expects"}</constant>
  </setHeader>
  <to uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&amp;inputSource=header&amp;inputSourceName=MyCustomMap"/>
  <log message="Loading done!"/>
  <to uri="mock:end"/>
</route>

Request body: {"somedata":"exactly as endpoint expects"}

‌

Call with result stored in header

XML

 <route>
  <from uri="direct:start"/>
  <toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&amp;outputTarget=header&amp;outputTargetName=myHeader"/>
  <log message="Loading done!"/>
  <to uri="mock:end"/>
</route>

Result data will be stored in the header myHeader.

‌

Call with result stored to property

XML

<route>
  <from uri="direct:start"/>
  <toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&amp;outputTarget=property&amp;outputTargetName=myProp"/>
  <log message="Loading done!"/>
  <to uri="mock:end"/>
</route>

Result data will be stored to the property named myProp.