End-to-end procedure to federate a BAW instance with PFS

. 1

1 - Introduction. 2

1.1- IBM Business Automation Workflow.. 2

1.2 - IBM Process Federation Server. 3

1.3 - What will be done in this procedure. 4

2 - Running Opensearch.. 4

2.1 - Why you need Opensearch. 4

2.2 - Running OpenSearch with Docker Compose. 5

3 - Configure BAW to index data into OpenSearch.. 6

3.1 - Configure the Federated Data Repository connection. 7

3.1.1 - Reference OpenSearch in BAW.. 7

3.1.2 - Add OpenSearch Certificate to BAW Truststore. 7

3.2 - Enable and configure FDR Process Indexing. 8

4 – Create the PFS server and configure common components. 9

4.1 - Generating the PFS configuration from a template. 9

4.2 - Configure common components of PFS. 10

4.2.1 - Configure the connection between PFS and OpenSearch. 10

4.2.1.1 - Declare the OpenSearch connection in the server.xml file. 10

4.2.1.2 - Configure PFS to trust the TLS certificate exposed by OpenSearch. 11

4.2.2 - Configure PFSDB to store saved searches. 13

4.2.2.1 - Create the PFSDB database. 13

4.2.2.2 - Reference the PFSDB database in server.xml 13

4.2.3 - Configure the user registry. 14

4.2.4 - Configure the security roles. 15

4.2.4.1 - Configure the J2EE security roles. 16

4.2.4.2 - Configure the Liberty administrator role. 17

5 - Federate the BAW System.. 18

5.1 - Add the BAW TLS certificate to PFS truststore. 18

5.1.1 - Extract the BAW TLS certificate. 18

5.1.2 - Import the BAW TLS certificate into PFS truststore. 19

5.2 - Configure Single-Sign-On between PFS and BAW.. 19

5.2.1 - Share LTPA key between BAW and PFS. 19

5.2.1.1 - Export the LTPA key from BAW.. 20

5.2.1.2 - Import the LTPA key in PFS configuration. 21

5.2.2 - Configure SSO domain. 21

5.2.2.1 - Configure SSO domain on BAW.. 21

5.2.2.2 - Configure SSO domain on PFS. 22

5.3 - Declare the BAW federated system in the PFS configuration. 23

5.4 - Configure BAW to use PFS as backend for Workplace and Process Portal 24

5.4.1 – Set PFS as backend. 24

5.4.2 Configure Cross-Origin Resource sharing (CORS) 25

6 - Run the federated topology. 26

6.1 – Start PFS. 26

6.2 - OpenAPI UI 27

6.3 - Check that the BAW federated system is successfully federated. 27

6.4 - Accessing Workplace. 28

6.5 - Accessing Process Portal 28

7 - Conclusion.. 29

1 - Introduction

1.1- IBM Business Automation Workflow

IBM Business Automation Workflow (BAW) is a platform to create workflow applications to improve productivity.

Workflow applications coordinate work between tasks performed by humans and automated tasks to improve daily business operations. Workflow applications have four main components:

·      An authoring environment to create and configure the application.

·      Frameworks or models for sequencing and delegating work. With Business Automation Workflow, the models can be either structured processes or unstructured cases. You can choose your model based on the pattern of your workflow and not be limited to a case or a process.

·      A user experience for interacting with the application. To provide consistent user experiences, standardized workflows can be reused across the organization.

·      Administrative tools for optimizing how the application runs, deploying new versions and managing security.

IBM Business Automation Workflow ships different runtimes which can work together:

·      The Business Process Management (BPM) runtime, which allows your business users to work on processes which will be initially implemented in the Web Process Designer of your BAW authoring environment. Instances of such processes are worked through the execution of human or automated tasks.

·      The Case management runtime which allows your business users to work on case management solutions which are based on closely related cases. Case workers can then create instances of this case solution and complete associated work items. Such work items can consist of starting a new instance of a BPM process.

1.2 - IBM Process Federation Server

IBM® Process Federation Server is an optional component for Business Automation Workflow environments. Process Federation Server runs on IBM WebSphere® Application Server Liberty.

Install this component to create a federated process environment that provides business users with a single point of access to their task list and launch list, regardless of the type of process that they are working on and the Business Automation Workflow back-end system on which the process artifacts are stored.

Consider installing Process Federation Server when your process applications are deployed in different Business Automation Workflow deployment environments. Without PFS, your users must log on to several different instances of Process Portal to get their work done, which is an inefficient and unfriendly user experience.

You may have to deal with multiple BAW instances if:

·      For scalability concerns your workload is too large to fit in a single BAW instance,

·      You are migrating to a newer version of BAW. In such case you can set up PFS to federate the old BAW instance and the new BAW instance, making it transparent to your business users who will seamlessly continue working on existing process instances on the old BAW instance while only starting new process instances on the new BAW instances. And at some point, when all process instances residing on the old system will be completed, you will be able to decommission this old BAW systems.

PFS requires data about processes, tasks, and cases from the federated BAW systems to be indexed into the “Federated Data Repository (FDR)”. The FDR can be either Opensearch or Elasticsearch. The indexing of these documents can be performed either by BAW or by PFS depending on the type (Process, Case or BPEL) and the version of the system to federate.

PFS also exposes REST APIs to provide users with the Process Federation Server features (generally through Workplace, Process Portal, or a custom web application) by:

·      Retrieving information from federated systems through the retrievers (Launch Entities and Systems Metadata REST APIs).

·      Performing searches into the federated data repository indexes to return lists of tasks, process instances and case instances (Tasks List and Process Instances list REST APIs)

·      Storing saved searches in Process Federation Server database (Saved search REST API).

·      Storing reusable queries in a federated data repository index (Reusable queries V2).

·      Returning data for the Team Performance Dashboard.

Process Federation Server also uses a relational database to store saved searches.

For more information regarding PFS:

https://www.ibm.com/docs/en/baw/25.0.0?topic=management-installing-enabling-process-federation-server

1.3 - What will be done in this procedure

This procedure outlines the step-by-step configuration procedure to have PFS federating a single BAW system using OpenSearch. It is assumed that you have already an existing installation of BAW and a fresh installation of PFS.

2 - Running Opensearch

2.1 - Why you need Opensearch

As mentioned earlier, PFS needs to have data about the systems it federates into the so-called “Federated Data Repository” (FDR). The FDR can be either Opensearch or Elasticsearch.

In this current procedure:

·      OpenSearch acts as the Federated Data Repository (FDR) where BAW indexes process, task, and case data.

·      PFS queries OpenSearch to provide consolidated search results across federated BAW systems.

·      Opensearch enables scalable, secure, and efficient retrieval of federated runtime data.

2.2 - Running OpenSearch with Docker Compose

To deploy OpenSearch as the Federated Data Repository (FDR), you can define its configuration in a docker-compose.yml file. This file describes the container settings, ports, authentication, and certificates required for OpenSearch to function correctly.

Before running OpenSearch on your machine, you should disable memory paging and swapping performance on the host as documented here: https://docs.opensearch.org/2.19/getting-started/quickstart/#starting-your-cluster

In this procedure, you will create a single node Opensearch cluster with security features enables. Note that single node Opensearch clusters are not appropriate for production environments. In production environments you should have at least 3 nodes in your Opensearch cluster to provide High Availability.

Create a file named docker-compose.yml with the following content:

With the above configuration the data stored in OpenSearch will be persisted locally in the ./data folder. You must grant sufficient privileges for the docker container to write into this folder. This can be achieved by executing the following commands:

You must also set the OPENSEARCH_INITIAL_ADMIN_PASSWORD environment variable in your shell or .env file.

You can now start OpenSearch by running the following command:

You can now test if OpenSearch is running by accessing https://localhost:9200/ and authenticating as admin user with the password you have used to set the OPENSEARCH_INITIAL_ADMIN_PASSWORD environment variable. You should get the following response:

3 - Configure BAW to index data into OpenSearch

Business Automation Workflow 24.0.0 and later can index data about process instances and tasks in the federated data repository. To enable this, you must:

·      Configure the Federated Data Repository connection in BAW:

o   Reference the Opensearch URL and credentials in BAW configuration,

o   Add the OpenSearch TLS certificate to BAW truststore.

·      Enable the FDR process indexing in BAW.

3.1 - Configure the Federated Data Repository connection

3.1.1 - Reference OpenSearch in BAW

To reference the Opensearch URL and credentials in BAW configuration, you must create a properties file as documented here:
https://www.ibm.com/docs/en/baw/25.0.0?topic=indexes-configuring-federated-data-repository-connection
And create Authentication alias:
https://www.ibm.com/docs/en/bpm/8.5.6?topic=cmd-creating-authentication-alias-3

3.1.2 - Add OpenSearch Certificate to BAW Truststore

To establish a secure connection between IBM Business Automation Workflow (BAW) and OpenSearch, it's necessary to add the OpenSearch certificate to the BAW truststore.

o   Ensure the OpenSearch server is up and running.

o   In the WAS Admin Console, navigate to SSL certificate and key management > Key stores and certificates

o   Open the cell default truststore details

o   Go to Signer certificates > Retrieve from Port.

o   Enter the OpenSearch hostname, port, and a custom alias.

o   Click Retrieve Signer Certificate and save the certificate to complete the import.

o   The certificate will now appear in the Signer certificates list:

3.2 - Enable and configure FDR Process Indexing

Now that the OpenSearch connection is properly set up in BAW, we will proceed with enabling the indexing of process instances and tasks.

On the BAW server, modify the 100Custom.xml file to activate Federated Data Repository (FDR) Process indexing.

Set the following configuration in the <BAW_HOME>/profiles/<DMGR_PROFILE>/config/cells/<CELL_NAME>/nodes/<NODE_NAME>/servers/<SERVER_NAME>/process-center/config/100Custom.xml file:

After the file has been updated, you must synchronize the WAS nodes, and restart the BAW/WAS server:

·      To synchronize the WAS nodes:

o    In WAS console, go to System administration > Nodes

o   Select your node and click Full Resynchronize

o   Wait for the synchronization to be completed

·      To restart the server:

o   In WAS console, go to Servers > Server Types > Websphere application servers

o   Select your server and click Restart

For more information about enabling and configuring de FDR process indexing: https://www.ibm.com/docs/en/baw/25.0.0?topic=indexes-enabling-federated-data-repository-process-indexing

4 – Create the PFS server and configure common components

Now that the BAW system is indexing data about process instances and tasks, we will proceed with configuring PFS.

This will be achieved by:

·      First generate the PFS configuration from a template

·      Then set the PFS components configuration as appropriate

·      And finally add the configuration to reference the BAW system as a federated system

The following documentation provides a detailed overview of what needs to be achieved to configure PFS: https://www.ibm.com/docs/en/baw/25.0.0?topic=environment-roadmap-configuring-process-federation-server-federated-environments

4.1 - Generating the PFS configuration from a template

Before starting this section, create the required databases (PFSDB) as described in section 4.2.2.1, or simply follow the steps provided in the reference link below:

https://www.ibm.com/docs/en/baw/25.0.0?topic=database-oracle

Reference path for scripts created under section:

cd /opt/IBM/WebSphere/Liberty/ibmProcessFederationServer/wlp-ext/dbscripts/
Here is how you can create a new PFS server from a template:

·      Go to the bin folder of the PFS installation:

       ·  Create the server using ibmProcessFederationServer template by running the following command where myPfsServer is the server name

      ·    Go to /opt/IBM/WebSphere/Liberty/usr/servers directory and verify that it contains a folder named myPfsServer is created

·      The file located at /opt/IBM/WebSphere/Liberty/usr/servers/myPfsServer/server.xml  contains the Liberty configuration that you will now adapt as appropriate to match the current topology.

4.2 - Configure common components of PFS

Now that the server has been created from the template, you will now configure the common components:

·      The connection to OpenSearch

·      The PFS relational database to store saved searches

·      The user registry and security roles

4.2.1 - Configure the connection between PFS and OpenSearch

In this section, we will configure how PFS can access OpenSearch.

4.2.1.1 - Declare the OpenSearch connection in the server.xml file

First, you must edit the server.xml file to configure the <ibmPfs_remoteElasticsearch> configuration tag to reference the URL to Opensearch and the credentials that will be used by PFS to authenticate against OpenSearch:

Here, set endpoints to the URL where OpenSearch is accessible and set password OpenSearch to the value you used to set OPENSEARCH_INITIAL_ADMIN_PASSWORD environment variable.

4.2.1.2 - Configure PFS to trust the TLS certificate exposed by OpenSearch

For PFS to be able to communicate with the HTTPS endpoint exposed by OpenSearch, you will have to:

§  Export the TLS certificate exposed by OpenSearch

§  Create a truststore for PFS

§  Import this certificate into PFS truststore

§  Reference the truststore in PFS configuration

4.2.1.2.1 - Export the TLS certificate exposed by Opensearch

To export the TLS certificate exposed by Opensearch:

§  Open the OpenSearch URL in a web browser.

§  Click on “Not Secure” in the address bar.

§  Select “Certificate is not valid”.

§  Go to the “Details” tab — this will display the certificate chain (typically includes two certificates).

§  Export the top-level certificate from the chain.

§  Save it as: /opt/IBM/WebSphere/Liberty/usr/servers/myPfsServer/resources/security/os.crt

4.2.1.2.2 - Create a truststore for PFS

We will now create a new truststore which will later be used by PFS.

§  Go to folder: /opt/IBM/WebSphere/Liberty/usr/servers/myPfsServer/resources/security

§  Execute the following command using the Java keytool utility:

§  You should now have a new truststore located at /opt/IBM/WebSphere/Liberty/usr/servers/myPfsServer/resources/security/pfs-store.p12

4.2.1.2.3 - Import Opensearch TLS certificate into PFS truststore

We will now import the Opensearch TLS certificate into the PFS truststore by executing the following command:

4.2.1.2.4 - Reference the truststore in PFS configuration

In PFS server.xml, file you must reference a keystore and a truststore. For the sake of simplicity, we will use the same store as keystore and truststore.

Here is how to configure this in server.xml:

§  Enable the ssl-1.0 feature as follows:

§  Declare the keystore, trust store and SSL settings as follows:

At this stage, the PFS is expected to be successfully configured to communicate with Opensearch.

4.2.2 - Configure PFSDB to store saved searches

PFS can persist search definitions created by end users. These search definitions are stored in a relation database. The current section will cover how to:

o   Create the PFSDB database,

o   Reference it in the server.xml file.

4.2.2.1 - Create the PFSDB database

You must follow the following documentation to create the database to store saved search definitions: https://www.ibm.com/docs/en/baw/25.0.0?topic=server-creating-process-federation-database 

4.2.2.2 - Reference the PFSDB database in server.xml

To reference the PFSDB database in server.xml, you must configure the <ibmPfs_federatedPersistence> tag which itself will reference a <dataSource> configuration.

Here is an example of how it could be configured when using a DB2 database, adapt the following sample to make it match your actual database which can be DB2, DB2 for z/OS, Oracle, SQL Server:

4.2.3 - Configure the user registry

It is required that PFS and its federated systems share the same user registry.

You have options to achieve this:

o   If the BAW system is configured to use basic authentication:

·      Ideally, you should configure PFS Liberty server to use the same LDAP as the one configured on the BAW system. To achieve this, follow this documentation: https://www.ibm.com/docs/en/was-liberty/base?topic=liberty-configuring-ldap-user-registries-in

·      But as configuring LDAP can be relatively complex, in dev environments, for the sake of simplicity, you may declare simply the same set of users in a basic user registry defined on PFS and BAW.

o   If the BAW system is configured to use OpenId Connect, then you should configure PFS to be a Relying Party (RP) of the same OpenID Connect Provider(OP) as the one used by BAW. To achieve this, follow this documentation: https://www.ibm.com/docs/en/was-liberty/base?topic=liberty-configuring-openid-relying-party-in

In the current procedure, we will only cover how to configure BAW and PFS to share the same basic registries

To declare a user in BAW basic registry:

o   Open WAS console, and go to Users and Groups > Manage Users

o   Click on Create

o   And fill in the field to create a single user as follows:

You can now declare the same user in the server.xml file as follows:

You can repeat the above procedure to create as many users as you want, but in production environments, you should configure LDAP or OpenID Connect.

4.2.4 - Configure the security roles

In Liberty, we can now reference the security roles and assign users or groups to each of them.

4.2.4.1 - Configure the J2EE security roles

Here a sample showing how to declare the J2EE security roles:

For more details about the security roles, go to: https://www.ibm.com/docs/en/baw/25.0.0?topic=portal-federated-systems-authorization-saved-searches

4.2.4.2 - Configure the Liberty administrator role

You can also declare the Liberty administrator role as follows to declare which users or groups will be allowed to access the PFS MBeans which allow to monitor and administer PFS:

For more details about PFS MBeans, go to: https://www.ibm.com/docs/en/baw/25.0.0?topic=server-monitoring-administering-mbeans

5 - Federate the BAW System

PFS common configuration is now ready, we will now proceed with adding a federated system.

This requires multiple actions:

·      Add the BAW TLS certificate to PFS truststore

·      Configure Single-Sign-On between PFS and BAW

·      Share the same LTPA key between PFS and BAW

·      Declare BAW as a federated system in PFS configuration

5.1 - Add the BAW TLS certificate to PFS truststore

To prevents SSL/TLS handshake failures when PFS make requests to the BAW federated system, the BAW TLS certificate must be added to PFS truststore. In this section we will:

·      Export the BAW TLS certificate

·      Add it to PFS truststore

5.1.1 - Extract the BAW TLS certificate

Here is how to extract the BAW TLS root certificate:

o   Log in to the WAS console at https://<BAW_Host>:9043/ibm/console

o   Navigate to Security > SSL Certificate and Key Management.

o   Select Keystores and Certificates.

o   Click on the cell default truststore.

o   Open Signer Certificates.

o   Select the root certificate

o   click Extract it,

o   Provide a file name on the machine running BAW, use Binary DER data as data type, and click apply

o   And finally move the certificate to the machine running PFS at /opt/IBM/WebSphere/Liberty/usr/servers/myPfsServer/resources/security/bawroot.crt

5.1.2 - Import the BAW TLS certificate into PFS truststore

To import the BAW TLS certificate into PFS truststore, go to /opt/IBM/WebSphere/Liberty/usr/servers/myPfsServer/resources/security and execute:
keytool -import -trustcacerts -alias baw -file bawroot.crt -keystore pfs-store.p12 -storetype pkcs12

5.2 - Configure Single-Sign-On between PFS and BAW

It is required to configure Single-Sign-On (SSO) between PFS and its federated systems. Achieving this requires 2 actions:

·      Share the same LTPA key between PFS and its federated systems,

·      Configure the same SSO domain on PFS and its federated systems.

5.2.1 - Share LTPA key between BAW and PFS

In this section, we will:

o   Export the LTPA key from the BAW system,

o   Reference it in the PFS configuration.

5.2.1.1 - Export the LTPA key from BAW

To extract the LTPA key from the BAW system:

§  Login to the WAS admin console and go to Security > Global Security

§  Under Authentication mechanism and expiration click on LTPA

§  Choose a password and path where you want the file to be exported

§  And then click on Export keys

§  Click on “OK”

5.2.1.2 - Import the LTPA key in PFS configuration

Now that the ltpa.keys file has been exported from BAW, you must move it to the /opt/IBM/WebSphere/Liberty/usr/servers/myPfsServer/resources/security folder on the machine running PFS. And then, uncomment the <ltpa> tag from server.xml and set the keysFileName  and keysPassword property as appropriate:

5.2.2 - Configure SSO domain

In this section, we will set the same SSO domain on BAW and PFS.

5.2.2.1 - Configure SSO domain on BAW

To configure the SSO domain on BAW:

§  Login to the BAW WAS Admin Console.

§  Navigate to: Security > Global Security

§  Under Web and SIP Security click on Single Sign-On (SSO)

§  Set Domain name to you company domain name (ex: “my.company.com”)

§  Click OK to save.

§  Restart the WAS server for the changes to take effect.

5.2.2.2 - Configure SSO domain on PFS

To set the same SSO domain PFS configuration, edit server.xml by uncommenting the <webAppSecurity> tag to reference the same domain under the ssoDomainNames property:

5.3 - Declare the BAW federated system in the PFS configuration

We will now declare the <ibmPfs_federatedSystem> and <ibmPfs_bpdRetriever> tags in the PFS configuration.

In the configuration commented from the template, you will find these 2 configuration tags along with <ibmPfs_bpdIndexer> and <dataSource> tags, as well as index.number_of_shards and index.number_of_replicas properties set to the <ibmPfs_federatedSystem> tag. You can delete these configuration tags and properties as they are only relevant when PFS is indexing data from the BAW federated system, and in our case, such indexing into FDR is already performed by BAW (see step 3 - Configure BAW to index data into OpenSearch   1).

You will simply need to set the following properties as appropriate to match the URLs to your BAW systems:

·       restUrlPrefix,

·       taskCompletionUrlPrefix,

·       portalSupportUrlPrefix,

·       internalRestUrlPrefix.

Notice also that the indexName property is set to bpm1 so that it matches the value set in 100Custom.xml to the property <fdr-index-name> :

For more information, refer to the links below:

·      https://www.ibm.com/docs/en/bpm/8.6.0?topic=systems-adding-bpm-system-federated-environment

·      https://www.ibm.com/docs/en/baw/24.0.x?topic=environment-process-federation-server-serverxml-configuration-file

5.4 - Configure BAW to use PFS as backend for Workplace and Process Portal

BAW provides the Workplace (and Process Portal) front-end application to allow business users to start new process instances and work on tasks. You will have to configure BAW so that Workplace (and Process Portal) uses PFS as backend to return federated lists of launchable entities, process instances and tasks.

To achieve this, we will:

·      Configure BAW to use PFS as backend for Workplace and Process Portal,

·      Configure Cross-Origin Resource Sharing (CORS) to allow Workplace and Process Portal to send request to PFS.

5.4.1 – Set PFS as backend

On the BAW server, modify the 100Custom.xml file to activate Federated Data Repository (FDR) Process indexing.

Add the following highlighted configuration in the <BAW_HOME>/profiles/<DMGR_PROFILE>/config/cells/<CELL_NAME>/nodes/<NODE_NAME>/servers/<SERVER_NAME>/process-center/config/100Custom.xml file, and set <bpm-data-endpoint> as appropriate to match the actual URL to PFS :

After the file has been updated, you must synchronize the WAS nodes, and restart the BAW/WAS server:

o   To synchronize the WAS nodes:

§  In WAS console, go to System administration > Nodes

§  Select your node and click Full Resynchronize

§  Wait for the synchronization to be completed

o   To restart the server:

§  In WAS console, go to Servers > Server Types > Websphere application servers

§  Select your server and click Restart

For more information about setting <bpm-data-endpoint> and <allowed-origins>:

o   https://www.ibm.com/docs/en/baw/25.0.0?topic=environment-configuring-endpoint-urls

o   https://www.ibm.com/docs/en/baw/25.0.0?topic=environment-configuring-allowed-origins

5.4.2 Configure Cross-Origin Resource sharing (CORS)

You must properly configure CORS on BAW for request from BAW to PFS.

This is achieved by using the wsadmin tool as like in the following example  where:

o   De1 must be replaced with the deployment environment name which you can find in WAS console under Servers > Deployment Environments.

o   pfs.my.company.com must be replaced with the hostname to PFS.

o   baw.my.company.com must be replaced with the hostname to PFS.

ex:

After making this change, you must restart the BAW server.

For more information:
https://ibmdocs-test.dcs.ibm.com/docs/en/baw/25.0.0?topic=environment-configuring-endpoint-urls

6 - Run the federated topology

Now, PFS and BAW should be properly configured, and you can start using PFS. In this section we will start PFS and verify that everything is working as expected.

6.1 – Start PFS

To start PFS, simply go to the bin folder of the PFS installation and run:

6.2 - OpenAPI UI

Once the PFS is started, you can now access the OpenAPI UI exposed by PFS at the following URL: https://pfs.my.company.com:9443/rest/bpm/federated/openapi

Log in as one of the users you declared in PFS basic registry, using the fully qualified user name. ex: uid=jdoe,o=defaultWIMFileBasedRealm

You should see the following UI:

 

6.3 - Check that the BAW federated system is successfully federated

Using the OpenAPI UI or a new browser tab, open https://pfs.my.company.com:9443/rest/bpm/federated/v1/systems .
In the JSON response, ensure that your system is properly returned with statusCode set to 200 as in the following example:

6.4 - Accessing Workplace

You can now try to access the federated Workplace at https://baw.my.company.com:9443/Workplace .

If after logging in as a user declared in the basic registries of both PFS and BAW, you still see a login dialog popping up, this means that Single-Sign-On is not properly configured and you should double check that the actions related to SSO have been successfully applied (see 5.2 - Configure Single-Sign-On between PFS and BAW     1).

Then you should try to start a new process and work on a task. If there is an error, check the web browser console first, and then the PFS logs.

You can also verify that PFS is properly used as backend by opening the web browser developer tools, and from the network tag, identify that the call to launchableEntities is sent to PFS (URL: https://pfs.my.company.com:9443/rest/bpm/federated/v1/launchableEntities ).

6.5 - Accessing Process Portal

Similarly, as in the previous section related to Workplace, you may test that Process Portal works fine by accessing: https://baw.my.company.com:9443/ProcessPortal

Additionally, you may test the creation of a saved search definition in Process Portal.

7 - Conclusion

You have now setup a topology where you have configured PFS and BAW as appropriate to have PFS federate a single BAW instance process engine.

To go further into building up your federated topology, you will configure PFS to federate other BAW instances following the same requirements as exposed above:

·      Share the same user registry between PFS and all its federated systems,

·      Configure Single-Sign-On between PFS and all its federated systems,

·      Adjust CORS as needed on the BAW instance hosting the federated Workplace and Process Portal so that it allows requests to be performed against all of the various BAW system federated by PFS.

·      Configure BAW (or PFS) so that data about this federated system is indexed into the same Federated Data Repository (FDR) as the one used by PFS (which was Opensearch in the current procedure).

·      Configure the federated system and retriever as appropriate in PFS server.xml configuration file.

Note also that in the current procedure, we have only federated the process engine of the BAW system.

As BAW also provides the Case management runtime, it is also possible for the same BAW instance to individually federate the Target Object Stores of the Case management system, and in such case:

·      Indexing of case instances into FDR would have to be configured on the BAW system as documented in https://www.ibm.com/docs/en/baw/25.0.0?topic=federation-indexing-case-instances

·      Each target object store to federated would have its own <ibmPfs_federatedSystem> and <ibmPfs_caseRetriever> tags in PFS server.xml configuration file as documented in https://www.ibm.com/docs/en/baw/25.0.0?topic=systems-configuration-properties-federated#rfps_indexoptions__caseretriever

Ackowledgements:
A special thanks to my colleague @Julien Carnec for his thorough review and guidance while preparing the blog.
Thankyou to my colleague @Prateek Gulur Suryanarayanarao for the guidance.