The id of the service activator that are gonna be used for the config aggregator to transform the folder service activator in a global service activator.

That param its mandatory.

  {
      "serviceActivatorMethod": "FOO",
      "serviceActivatorId": "bar",
      "path": "/foo/bar/"
  }

Will be transformed in...

{
     ...,
     "serviceActivators": {
         "bar": {
             "serviceActivatorMethod": "FOO",
             "path": "/foo/bar/"
         }
     }
}

Execute the service activator call asynchronously. This means, that the loading of a page is not blocked, when the service has not yet returned a result. Should not be set for the following page in the navigation. In this case, a service activator should just be executed synchronously Default: false

Ensures, that an asynchronous service activator call finishes successfully (i.e., "is resolved") before one of the pages with one of the "pageIDs" is shown. If the call has not yet returned, the display of the page will be delayed until it is returned.

If the same call is performed several times, it is considered as "resolved" as long as the latest call was successful. Therefore, a retry mechanism for unsuccessful calls could eventually mark the call as "resolved".

set to true to trigger stale state cleaning this is optional because it can be overriden by the pfeConfig "autoCleanState"

Defines the conditions to make the ServiceActivator call to the back-end. As it is an Array, you can define more then one condition and all of them must be TRUE to make the ServiceActivator call. (in short: it's an "AND" condition, not an "OR").

Example:

conditions: [ { expression: '{$.food} == "schnitzel"' }, { expression: '{$.price} > 1' } ]

Short message to communicate what the system is doing. You can pass an object with the keys headline (mandatory) and subline (optional). Alternatively, you can directly pass a string, which sets the headline of the spinner implicitly.

If set to "true", the SA don't emit serviceActivatorCallInProgress$ in that way you can make a call in your app and don't show the page loader (a.k.a LottieAnimations) If you want to trigger only before a page you can have a GlobalServiceActivator and then in the cfg

 {
     "globalConfigId": "myServiceActivator",
     "dontEmitInProgress": true
 }

If a pages have more than 1 OnEnter / OnLeave service activator and only one of them emit the event all emit the event.

Contains the error handling configuration for this service activator.

If no configuration is given, the default behavior of going to the global error page is active.

If a configuration is given, it will be activated in case of error responses.

Optional id of a service activator in the global config.

If a service activator with this id is found in the global config, it is used.

If there are additional attributes defined in this configuration, those will partially override the global configuration.

Will throw an error if used. Please use globalConfigId instead.

Boolean to enable undefined responses to be mapped to the state

The path of the service activator. This is defined by the BFF API.

Path params that appear in the path With this we are going to be able to build the complete url
Example: If we want to make a call to https://endpoint.com/contract/1 where that '1' is a value from the app then we should:

• Define path as endpoint/contract/{appValueId} IMPORTANT: No spaces in the dynamic content.
  
• Define pathParams as:
  [ {
  id: 'appValueId',
  value: jsonExpression
  } ]
  being jsonExpression, the expression to get from state the value.

Query params that appear in the url With this we are able to send params to the URL Example: If we want to make a call to https://endpoint.com/contract/1?date=2020-01-01 Where the date comes from the state we should:

• Define path as endpoint/contract/1
  
• Define queryParams as:
  [ {
  name: 'date',
  value: jsonExpression
  } ]
  being the jsonExpression the expression used to extract the value from the state.

Defines, how the state should be mapped to the request payload. This enables you to transform the state objects into anything you would like to send to the back-end API.

Example, if you have your state modeled like this:

{ "user": { "name": "Michael" "age": "33" }, "familyInformation": { "children": 1, "married": yes, } "sensitiveInformation": { "password": "1234", "creditcard": "1234-1234-1234-1234", } };

You probably want to avoid sending the "sensitiveInformation" object to the back-end, and for this example, lets glue the "user" and "familyInformation" objects into just one object called "userInfo" to show how we can manipulate/extend objects.

Your requestDataMapping configuration has to be like this:

{ requestDataMapping: [{ stateKeyExpression: '$.user', requestDataExpression: '$.userInfo' }, { stateKeyExpression: '$.familyInformation', requestDataExpression: '$.userInfo' }] }

Then the back-end API will receive this object:

{ "userInfo": { "name": "Michael" "age": "33" "children": 1, "married": yes, } };

Defines, how the response data should be mapped to the state.

Defines the HTTP call method. Use: POST, GET, PUT or DELETE

Custom response handling per service activator. See ServiceActivatorResponseStatusHandler interface.

List of possible userInputState updates To be executed before doing the service activator call

Defines, how the error response data should be mapped to the state. This will be done, before the navigation to the error page is triggered.

Please switch to the errorResponseDataMapping attribute in the new service activator errorHandling configuration

When the serviceActivatorErrorHandlingExcludeStatusCodes are used, the navigation is also triggered in case of an error. This flag can be used to activate the previous behavior, where the navigation was not done in case of http error responses. Please switch to the new disableErrorPageNavigation attribute in the service activator errorHandling configuration

A list of http status codes, that will not be treated as an error by the service activator response handling. For these status codes, the response handling will be executed. This makes it possible to use error status codes for validation errors.

The navigation will not be prevented in this case. Use the preventNavigationOnError flag to stay on the page.

For a more complex response handling, it is possible to extend the PfeServiceActivatorService and to implement a custom functionality. Please switch to the new service activator errorHandling configuration