Flow and Backend Integration
- 1. Overview of Backend Integration Approaches
- 2. Service Activators
- 3. Actions
- 4. Custom Triggers within Components
- 5. Order of Execution
1. Overview of Backend Integration Approaches
| Approach | Strengths | Weaknesses | Well Suited Example |
|---|---|---|---|
| Service Activators | Quick integration via pure configuration. Very well suited for simple calls, with a limited complexity | The configuration gets difficult to handle beyond a certain complexity of the call | Fetch data to fill in dropdown selections |
| PFE Actions | Make it possible to trigger code from within the customer journey flow via custom PFE actions. Well suited to handle complex backend communication with large data models. As this can be any code, it would for example be possible to use code generation approaches like with openAPI (swagger). Can also handle use cases that go beyond pure backend communication | Requires an implementation in code and integration of it in the application | Fetch offerings or create a contract with lots of fields |
2. Service Activators
PFE Service Activators provide an out of the box functionality to trigger calls at certain points in a flow by configuration.
See here for a more detailed explanation on how to use them.
3. Actions
PFE Actions make it possible to trigger functions via hooks in the navigation. This makes it possible to integrate the flow with a more complex backend integration handled in code. This could for example be code that got generated based on an openAPI (swagger) compliant API specification.
This is especially recommended for integration scenarios that go beyond a certain level of complexity and are cumbersome to handle with service activators.
The approach makes it possible to keep the trigger flexibility of a service activator, while providing an increased safety in regard to the data model as well as a more powerful handling of the API calls.
A real life implementation and further information about this approach can be found here
Additionally, Service Activators can also be triggered through an action.
See also here for a more detailed explanation on how to implement custom PFE Actions.
4. Custom Triggers within Components
Backend calls can also be triggered by custom code within a component.
This is especially useful for components that provide some kind of user interaction that results in a selection. For example the search of a vehicle.
5. Order of Execution
There are several trigger points during a flow that can be used for integration with backend systems or other functionalities.
Actions and service activators are executed in a certain order during the navigation.
This also influences if they are triggered in all cases and which information they can use in the conditions.
5.1. Forward Navigation
A forward navigation is usually triggered by the user clicking on the Next button.
The onPageLeaveActions and service activators are then executed. The determination of the next page can then use the result of those in the conditions. This makes it possible to navigate in different ways, dependent on those results. For example dependent on a backend response.
5.2. Backward Navigation
5.3. busy$ Observable
The PFE provides the busy$ observable that signals if a service activator, PFE action or navigation is currently running.
It can be used like this:
this.pfeBusinessService.busy$.subscribe((busy) => {
this.navigationOrServiceActivatorInProgress = busy;
});5.4. serviceActivatorCallInProgressDetails$ Observable
The serviceActivatorCallInProgressDetails$ observable provides the ability to subscribe to a list of the configurations of the currently running service activators.
Usage example:
this.pfeBusinessService.serviceActivatorCallInProgressDetails$.subscribe((configs: NavServiceActivatorConfig[]) => {
this.spinnerMessage = configs[0]?.displayMessage;
});