Configuring WebSphere in a cluster to work with Bizagi

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Bizagi system administration > Bizagi server configuration > Bizagi Engine JEE platform configuration > Configuring a JEE application server to work with Bizagi > WebSphere configuration > Clustered WebSphere configuration >

Configuring WebSphere in a cluster to work with Bizagi

When using WebSphere to work with Bizagi in a cluster (use of more than 1 node for load balancing purposes), you need to have already set up your WebSphere for cluster support.

Therefore, before you move on, make sure you have carried out the steps described at Preconfiguring WebSphere for cluster support.

For more information about the procedure's overview, refer to Clustered WebSphere configuration.

This section focuses on the configuration needed in your WebSphere cluster so that your Bizagi project is set up.

 

 

What you need to do

Once you have achieved these previous steps, these steps are carried out, as described further on this section:

 

1. Install libraries used by Bizagi into WebSphere.

2. Configure files for Bizagi's runtime.

3. Set environment variables.

4. Configure the following modules in WebSphere:

Data access

Messaging service (JMS)

Authentication and Bizagi system user

 

These modules are configured by using WebSphere's administration console and by referencing the libraries and drivers installed in the first step.

After these steps, your WebSphere installation will be configured in a clustered setup, for Bizagi processes to be deployed as a JEE application (i.e generate the Work Portal).

 

 

Procedure

The following steps describe in detail how to configure and modify settings of the default WebSphere installation in order to work with Bizagi.

 

note_pin

Always use the names and information as presented below, keeping in mind that these are case-sensitive.

 

 

1. Install Bizagi libraries into WebSphere

For WebSphere to work with Bizagi, you will need to install libraries and drivers that Bizagi uses into your WebSphere installation.

Such libraries and drivers are not shipped in a WebSphere installation by default.

 

To do this, you will need to have at hand the configuration and deployment files delivered by Bizagi (BizAgi-ear-Websphere-dist.zip).

Once having this .zip file, extract its contents into a local path of your choice.

This path, including its immediate sub-folder called BizagiBPMJEE, will be referenced as <CONFIGURATION_INPUTS> from this moment on.

In this image, <CONFIGURATION_INPUTS> references C:\ROOT\BizAgi-ear-WebSphere-dist\BizagiBPMJEE\:

 

WebSphere85_copyfiles00

 

 

1.1 Install Authentication libraries

Installing the authentication libraries is simply done by copying those libraries used by Bizagi's Authentication module provided in the Configuration inputs.

To do so, copy the Authentication module libraries (bizagi-websphere-security-[version].jar, bizagi-remote-[version].jar, bizagi-security-common-[version].jar) provided in the Configuration inputs, from this path:

<CONFIGURATION_INPUTS>\security\

Into WebSphere libraries at:

<WEBSPHERE_HOME>\lib\ext\

 

WebSphere85_copyfiles02

 

 

1.2 Install additional libraries

Installing other libraries is simply done by copying those libraries such as: the one used for log purposes called log4j-[version].jar, and the one used by the persistence framework called eclipselink-[version].jar.

Since both are provided in the Configuration inputs, copy them from this path:

<CONFIGURATION_INPUTS>\configuration\

Into WebSphere libraries at:

<WEBSPHERE_HOME>\lib\ext\

 

Make sure you edit the name of the eclipselink library so that it does not specify its version detail (rename it as eclipselink.jar):

 

WebSphere85_copyfiles03

 

1.3 Install shared libraries

Installing 2 shared libraries is done by copying those libraries as provided in the Configuration inputs at <CONFIGURATION_INPUTS>\configuration\into WebSphere's optional libraries path.

To do so, copy the httpclient-4.1.1.jar and the httpcore-4.1.jar files into:

<WEBSPHERE_HOME>\optionalLibraries\

 

 

1.4 Install drivers

Installing the drivers is done by copying those libraries according your database engine, as provided in the Configuration inputs.

To do so, copy the drivers provided at <CONFIGURATION_INPUTS>\configuration\, into WebSphere libraries at:

<WEBSPHERE_HOME>\lib\ext\

 

If your project uses Oracle, copy the ojdbc6-11.1.0.6.0.jar driver.

If your project uses SQL Server, copy the sqldbc-4..0.jar driver.

Additionally, copy the bizagi-jdbc-driver[version].jar as well.

 

 

2. Configure files for Bizagi's runtime

There are certain configuration files that Bizagi will internally use and will look up for, when executing the processes, such as: A JiNET module and a set of properties files holding special settings in your specific project.

You need to initially define where you will have these files so that referencing them is configured when setting the environment variables that WebSphere will use in its startup.

 

To ensure you can manage the configuration involved for Bizagi to work (i.e creating backups for the system's configuration), we recommend copying these configuration files into a separate path.

This path will be referred to as <BIZAGI_HOME> from this point on.

 

note_pin

It is recommended that your <BIZAGI_HOME> path is contained inside of the WebSphere installation directory and that the owner of this folder is the same user running WebSphere.

This way, you can ensure proper access rights (this path should have at least read and write rights).

It is also recommended to place inside of <BIZAGI_HOME>, the JEE Console Manager for the application deployment procedure.

 

To configure the files used by Bizagi, first copy:

The JiNET folder (located at <CONFIGURATION_INPUTS>) into <BIZAGI_HOME>

The bizagi-config folder (located at <CONFIGURATION_INPUTS>) into <BIZAGI_HOME>

The connectors folder (located at <CONFIGURATION_INPUTS>) into <BIZAGI_HOME>

 

WebSphere85_copyfiles01_cluster

 

 

 

 

 

note_pin

If your processes use Bizagi's built-in integration with SAP systems, you will need to configure the libraries involved in the connection to SAP throughout the connector for JEE platforms.

 

The SAP connector for JEE platforms  (called JCo) consists of a .jar file and an additional native library for the operating system (a .so file for a Unix-like OS such as Linux, or a .dll for a Windows OS).

All JCo required files are requested and downloaded from the same official SAP link at http://service.sap.com/connectors (authorized access by using your valid SAP credentials required).

Make sure you obtain the library that corresponds to your system architecture bits specification (i.e, 64-bit or 32-bit).

 

Once you have the JCo library, make sure you:

1. Place the sapjco-3.x.jar library in your JEE Application server's repository of libraries, at <WEBSPHERE_HOME>/lib/ext/.

2. Place the sapjco3.so (for a Unix-like OS such as Linux) or the sapjco3.dll (for a Windows OS) in your Bizagi server, at <CONFIGURATION_INPUTS>/connectors/SAP/.

 

In the next section (set environment variables) you will need to include this path as a starting parameter of the environment variables.

 

3. Set environment variables

To set environment variables which will be referenced at the server's startup, first start your WebSphere Server.

Then, access the administrative console to include these variables (by default accessed at https://localhost:9043/ibm/console/logon.jsp).

 

note_pin

Notice that when changing settings through the administration console, you will need to constantly save changes directly to the master configuration.

For this, you will see a Save link at the top of the console, right after clicking Apply or OK on the temporary changes.

 

Go to the Servers section and expand it to locate the Server Types. Expand this sub-section and click WebSphere application servers.

Click your Application server, which by default is server1.

 

WebSphere85_prep

 

Browse into the Server Infrastructure section, located at the second column.

In it, expand the Java and Process Management and click Process definition.

 

WSphere_1_02

 

On the appearing information, click on the Java Virtual Machine link, located at the Additional Properties section.

 

WSphere_1_03

 

Enter the following values and variables into the properties shown below:

Initial heap size: 1024

Maximum heap size: 1024

 

WebSphere85_JVMarguments

 

note_pin

These values are suggested as maximum and minimum of memory to correctly deploy Bizagi. Otherwise lack of memory errors may appear, leading to a corrupt installation.

 

Generic JVM arguments:

-DiNET_HOME=<BIZAGI_HOME>\JiNET -Duser.language=en -Duser.country=US -Dfile.encoding=UTF-8 -Dcom.ibm.websphere.webservices.soap.enable.legacy.get.behavior=true

 

 

WebSphere85_JVMarguments3

 

note_pin

The variable -Dcom.ibm.websphere.webservices.soap.enable.legacy.get.behavior=true should be used, and it is specially needed for WebSphere to allow invoke web services having null headers.

 

Consider that you need to replace <BIZAGI_HOME> with the actual path as defined by you previously, while making sure you will use the appropriate folder separation character ("/" for Unix-like OS, and "\" for Windows OS).

 

note_pin

If your processes use Bizagi's built-in integration with SAP systems, you will need to configure the libraries involved in the connection to SAP throughout the connector for JEE platforms, as mentioned in the above section.

 

Once you have placed the JCo libraries in your corresponding server paths, add the following part to the already modified environment variables of the Generic JVM arguments:

-Djava.library.path=<BIZAGI_HOME>\connectors\SAP\jco3

 

Consider that you need to replace <BIZAGI_HOME> with the actual path of the files Bizagi will use in its runtime, while making sure you will use the appropriate folder separation character ("/" for Unix-like OS, and "\" for Windows OS).

 

WebSphere85_sap

 

Click on OK and then on Save to apply these changes.

 

WSphere_1_05

 

 

Browse again into the Java Virtual Machine link (located at the Additional Properties section).

 

WSphere_1_06

 

Click the Custom properties link.

Create the following properties:

APP_SERVER: Internal property used by Bizagi for special management to the given JEE Application server.

bizagi-config: Path property used by Bizagi to load information from additional configuration files.

This path specified needs to contain the bizagi-extended.properties file.

bizagi.cache.multicast.enabled: Boolean property to enable the use of distributed caché in clustered setups.

bizagi.cache.multicast.address: String type property to specify the broadcasting IP address for the synchronization carried out in the nodes. By  default, the 224.2.2.3 IP is used.

bizagi.cache.multicast.port: Numeric property to specify the port used to carry out the synchronization in the nodes. By default, the 7777 port is set.

bizagi.cache.multicast.type:String type property to specify the protocol used for the synchronization in the nodes.allowed values are: UDP (default) and DB.

com.ibm.websphere.webservices.soap.enable.legacy.get.behavior: Used as true to allow WebSphere to support invocation of web services having null headers.

 

To create these properties, click on New to register the custom property and its value.

Name the first property as APP_SERVER, and specify that its value is WEBSPHERE.

 

WSphere_1_07

 

Click Ok.

Click the New button to create the second custom property.

Name this property as bizagi-config, and specify that its value is the path that points to the bizagi-config folder (where the bizagi.extended.properties file is located, at <BIZAGI_HOME>).

Example: \usr\share\bizagi-config\

 

WebSphere85_bizagiconfig

 

 

Click Ok and click again on New to register another custom property (the third one).

Name it: bizagi.cache.multicast.enabled, and specify its value as: true.

 

Click Ok and click again on New to register another custom property (the fourth one).

Name it: bizagi.cache.multicast.address, and assign in its value, the IP address.

 

Click Ok and click again on New to register another custom property (the fifth one).

Name it: bizagi.cache.multicast.port, and assign in its value, the port to be used if you don't want the default one.

 

Click Ok and click again on New to register another custom property (the sixth one).

Name it: bizagi.cache.multicast.type, and specify its value as: UDP.

 

Click Ok and click again on New to register another custom property (the last one).

Name it: com.ibm.websphere.webservices.soap.enable.legacy.get.behavior, and specify its value as: true.

 

Click on OK and then on Save to apply these changes.

Keep in mind that you need to do the aforementioned for each node of your cluster.

 

When you are done with all your clusters, restart your WebSphere services.

 

 

4. Configure WebSphere modules

There are some modules to configure as described in detail below, which are mainly set through WebSphere administration console.

 

4.1 Data access configuration

Before moving on, take into account that if you are using a SQL Server Database, you will require that its service is not started under a dynamic port.

It is required that this TCP/IP port is set explicitly (i.e its default 1433 port).

 

SQLServer_explicitPort

 

 

For the following configuration, access the administration console and perform the described steps. Notice that in some of them, there will be input according to your Database Engine (Oracle or SQL Server).

 

First, we will create and register a JDBC Provider.

To do this, access the administration console and go into the Resources section to expand the JDBC item. Click JDBC Providers.

 

Make sure you select the scope that includes your cluster (it should be listed as Cluster=[Cluster_name]):

 

NODE_config01

 

 

Create a Provider by clicking the New button.

In the new Provider configuration (done in 3 assisted steps), enter the following information, according to your Database Engine.

 

For Oracle:

oDatabase type: Oracle

oProvider type: Oracle JDBC Driver

oImplementation type: Connection pool data source

oName: Oracle JDBC Driver

 

NODEWSDS_07ora

 

Click Next.

Specify the full path to the Oracle driver (ojdbc), having <WEBSPHERE_HOME>\lib\ext\.

Keep in mind that you will need to configure the driver in this step with consideration of how your class path is defined so that it references the exact name of the .jar file.

Given that WebSphere by default will locate it as ojdbc6.jar, you will need to either redefine your class path so that it specifies the exact name as delivered by Bizagi (with the minor version detail, as ojdbc6-11.1.0.6.0.jar), or you will need to rename the physical file so that it is set as in the default class path (generic, exactly as ojdbc6.jar).

 

 

WebSphere85_ds_oracle

 

 

Click Next and review the summarized information. Click Finish when done.

 

For SQL Server:

oDatabase type: SQL Server

oProvider type: Microsoft SQL Server JDBC Driver

oImplementation type: Connection pool data source

oName: Microsoft SQL Server JDBC Driver

 

WebSphere85_sqlDS1

 

Click Next.

Specify the full path to the Oracle driver (sqljdbc), having <WEBSPHERE_HOME>\lib\ext\.

Keep in mind that you will need to configure the driver in this step with consideration of how your class path is defined so that it references the exact name of the .jar file.

Given that WebSphere by default will locate it as sqljdbc4.jar, you will need to either redefine your class path so that it specifies the exact name as delivered by Bizagi (with the minor version detail, as sqljdbc-4.0.jar), or you will need to rename the physical file so that it is set as in the default class path (generic, exactly as sqljdbc4.jar).

 

 

WebSphere85_sqlDS2

 

Click Next and review the summarized information. Click Finish when done.

 

 

Having created the Provider (either Oracle or SQL Server), it will appear listed in the table of Providers.

Keep in mind to click Save to apply the changes into the master configuration.

 

 

Now, we will create and register a Data Source for our connection.

To do this, locate the panel to the left to quickly click the Data sources link (still at the Resources section in the expanded JDBC item).

Make sure you select the scope that includes your cluster (it should be listed as Cluster=[Cluster_name]):

 

NODE_config02

 

Create a Data Source by clicking the New button.

In the new Data Source configuration, enter the following information:

Data source name: BizAgiJava

JNDI name: BizAgiJava

 

Click Next. Click Select an existing JDBC Provider to select the Data Provider according to your Database Engine (choose either the one for Oracle or SQL Server, as previously created).

 

WSDS_03

 

If you are using SQL Server, click Next and in the upcoming step, make sure that you: Enter the connection parameters to your SQL Server instance, and that you tick the Use this data source in container managed persistence (CMP) checkbox.

 

Consider:

odatabase_name: The name of your processes database.

oport_number: The port under which the Database service listens to.

oserver_name: The Database Server name.

 

WebSphere85_sqlDS3

 

If you are using Oracle, click Next and in the upcoming step, make sure that you: Select Oracle data store helper for the configuration regarding the Data Store helper class name, and that you edit the connection URL.

For the URL, enter the whole connection string to your Oracle instance. This should be formatted as:

jdbc:oracle:thin:@[database_server]:[port_number]/[service_name]

 

Consider:

odatabase_server: The Database Server name. You may choose to use the SID instead.

oport_number: The port under which the Database service listens. In Oracle, by default it is the 1521.

oservice_name: The service name to your Oracle instance ID.

 

NODE_config03

 

 

After setting the connection to your instance, click Next in the upcoming configuration screens (until your reach the end of the guided steps in which case you can click Finish to create the data source).

 

Click on the recently created BizAgiJava Data Source (which appears listed at the table, either for SQL Server or Oracle), to set its additional properties.

 

Click the Connection Pool properties link located at the Additional Properties section.

 

NODEWSDS_05_connection_pool_prop

 

Set the following values:

Maximum connections:        120

Minimum connections:        30

NODEWSDS_05_a

 

Click on OK and then on Save to apply these changes.

 

Click the WebSphere Application Server data source properties link located at the Additional Properties section.

 

NODEWSDS_05_datasource_prop

 

Set the following value:

Statement cache size:        200

 

NODEWSDS_05_b

 

Click on OK and then on Save to apply these changes.

 

Click the Custom properties link located at the Additional Properties section.

 

NODEWSDS_05

 

Edit the properties as described below, in order to assign the proper values of your Database connection.

 

For SQL Server:

oresponseBuffering: Set it to adaptive.

osendStringParametersAsUnicode: Its value depends on your specific project, regarding if it will will be supporting unicode. For unicode support, specify: true. Notice that for Unicode support, you should be using a collation and Bizagi setting for your project that supports Unicode.

owebSphereDefaultIsolationLevel: Set it to 2 (indicates READ-COMMITTED level).

In addition to this, create 2 new properties: user and password. For their values, consider:

ouser:

For Oracle, the user schema which represents your Bizagi project.

For SQL Server, the account login to access that instance.

opassword: The password of that user.

 

 

For Oracle:

owebSphereDefaultIsolationLevel: Set it to 2 (indicates READ-COMMITTED level).

In addition to this, create 2 new properties: user and password. For their values, consider:

ouser:

For Oracle, the user schema which represents your Bizagi project.

For SQL Server, the account login to access that instance.

opassword: The password of that user.

 

 

WSDS_06ora

 

 

After editing these properties, make sure you click Save to apply all changes.

Once you have the Data source set, you may click on the Data Source (BizAgiJava) to go back and use the Test connection button for verification purposes.

 

 

4.2 Messaging service configuration (JMS)

In these steps we will configure a JMS Server used by Bizagi to process Asynchronous Activities.

When working with WebSphere in a clustered configuration, it is important to create additional resources as well to handle a proper management of caché between the nodes, so that synchronization tasks do not affect the application's resources (use of messaging for caché).

 

To create all the necessary resources, access the administration console, and go into the Service integration section and click Buses.

 

NODEWS_JMS01

 

Service Integration bus

Click on New to create a bus to allow activation of the messaging services.

Enter BizAgiBus for its name, and make sure you unmark the Bus security checkbox.

 

WS_JMS02

Click Next, and then Finish to create the new bus.

 

WS_JMS03

 

Click the recently created bus appearing in the list (BizAgiBus) and then in the Bus members link in the Topology section.

 

WS_JMS04

 

 

Associate the server instance by clicking Add.

In the new bus member, ensure you tick Cluster to select your cluster from the drop-down list.

 

NODE_config04

 

Click Next.

Tick the Enable Messaging engine policy assitance? checkbox and then select Scalability with high availability as the policy type to use.

 

NODE_config05

 

 

Click Next.

Select File store as the type of message store to be used and click Next.

 

NODEWS_JMS06

 

Notice you will see a list of the messaging engines created automatically, and those which are not configured yet (as notified by the Is the message store configured = No).

Click the Name of the messaging engine to configure it (keep in mind you will need to configure all of them).

 

NODE_config06

 

To configure each messaging engine, you may keep the default values for all properties, but make sure you define 2 directories for logs and the filestore:

Log directory path: Set the path and directory in which logs associated to the node will be stored.

It is recommended to have a folder for this node, and a logs folder, e.g <WAS_HOME>\profiles\<NODE_NAME>\logs

Permanent store directory path: Set the path and directory for the filestore's location.

It is recommended to have a folder for this node, and a filestores folder, e.g. <WAS_HOME>\profiles\<NODE_NAME>\filestores

 

note_pin

You may create such path inside of <BIZAGI_HOME>, however the most important, usual and recommended aspect is that this folder is set inside of the WebSphere installation directory in order to avoid issues regarding the access rights (read and write rights as minimum; preferably having ownership set to the user running WebSphere).

 

 

NODE_config07

 

 

Click Next.

Repeat these last steps to configure each messaging engine, and then verify that all of them have been properly set (the Is the message store configured should show Yes).

 

Once you are done, configure memory use to boost the server's performance. Enter the following values and variables into the properties shown below:

Initial heap size: By default it is set to 256, but we recommend using 1024

Maximum heap size: 1024

Additionally, tick the Change heap size checkbox and click Next.

 

Verify the summary information presented before completing the procedure.

Click Finish when done and make sure you click Save and apply changes.

 

 

Destination resources

Back in the bus information, click the Destinations link (under the Destination resources section) to create and associate 2 queues for Bizagi to handle asynchronous capabilities (one for asynchronous tasks and one for logging purposes).

 

 

WS_JMS07

 

To create and associate the first queue (for asynchronous tasks), click on New to create a Destination which will be set as a queue (destination type = Queue).

 

WS_JMS08

 

Click Next. Set BizagiQueue as its identifier and a enter a description.

 

WS_JMS09

 

Click Next and ensure that the bus member as involved previously, is selected including your cluster (from the drop-down list):

 

NODE_config08

 

Click Next and then Finish to create the destination. You will see this destination listed under the destinations table.

 

WS_JMS11

 

Click on this recently created queue (BizAgiQueue) to edit its retries handling.

In this queue detail, edit the Maximum failed deliveries per message so that it is set to 1 (WebSphere will retry once any failed Asynchronous Activity execution, which means that this will be re-attempted as configured in Bizagi for its Asynchronous retries).

 

WS_JMS12

 

Click OK.

 

To create and associate the second queue (for logging purposes), back in the table, click on New again to create a Destination which will be set as as another queue (destination type = Queue).

 

 

WS_106_JMS01

 

Click Next.

Set BizagiQueueEvent as its identifier and a enter a description.

 

WS_106_JMS02

 

Click Next and ensure that the bus member as involved previously, is selected from the drop-down list.

 

Click Next and then Finish to create the destination. You will see this destination listed under the destinations table.

 

Click on this recently created queue (BizAgiQueueEvent) to edit its retries handling.

In this queue detail, edit the Maximum failed deliveries per message so that it is set to 1.

 

WS_106_JMS04

 

Click OK.

Remember to click Save in order to apply the changes into the master configuration.

 

 

JMS Connection factory

Now we will create 2 JMS Connection factories (one to be used by the asynchronous tasks in Bizagi and one for logging purposes).

Browse to the Resources section and expand the JMS item. Click Queue Connection factories.

Make sure you select the scope that includes your cluster (it should be listed as Cluster=[Cluster_name]):

 

 

NODE_config09

 

To create the first connection factory (for asynchronous tasks), click New.

For the new resource provider, keep the Default messaging provider and click OK.

 

NODEWS_JMS15

 

This will take you to define the main properties for the new connection factory.

Enter AsyncControllerFactory for both the Name and the JNDI Name. Ensure you select the bus created for Bizagi (BizAgiBus).

 

NODEWS_JMS16

 

Click Ok.

Click on the recently created AsyncControllerFactory (which appears listed at the table), to edit its connection timeout parameter.

 

NODEWS_JMS19

 

Click the Connection pool properties link located under the Additional Properties section.

 

Set the Connection timeout property to 120 seconds and click OK.

 

NODEWS_JMS21

 

 

 

To create the second connection factory (for logging purposes), click on New again making sure you have selected the scope that includes your cluster.

 

WS_106_JMF01

 

For the new resource provider, keep the Default messaging provider and click OK.

This will take you to define the main properties for the new connection factory.

Enter AsyncAuditControllerFactory for both the Name and the JNDI Name. Ensure you select the bus created for Bizagi (BizAgiBus).

 

WS_106_JMF02

 

Click OK.

Click on the recently created AsyncAuditControllerFactory (which appears listed at the table), and click the Connection pool properties link located under the Additional Properties section, to edit its connection timeout parameter.

 

WS_106_JMF03

 

Set the Connection timeout property to 120 seconds and click OK.

 

WS_106_JMF04

 

Click Save in order to apply the changes into the master configuration.

 

Queue resource.

Now we will create 2 Queue resources (one to be used by the asynchronous tasks in Bizagi and one for logging purposes).

To do this, locate the panel to the left for a quick access to the Queues link (still at the Resources section in the expanded JMS item).

Make sure you select the scope that includes your cluster (it should be listed as Cluster=[Cluster_name]):

 

To create the first queue resource (for the asynchronous tasks in Bizagi), click New.

Keep the Default messaging provider and click OK.

 

WSNODE_JMS22

 

Enter the following detail for the Queue resource:

Name: AsyncController

JNDI Name: jms/AsyncController

Bus name: select the previously created BizAgiBus.

Queue name: select the previously created BizAgiQueue.

 

NODE_config10

 

 

Click OK.

You should see the recently created Queue at the table.

 

NODEWS_JMS24

 

 

To create the second queue resource (for logging purposes), back in the table of queues, click New ensuring you have selected the corresponding scope that includes your cluster.

Keep the Default messaging provider and click OK.

 

WS_JMS22

 

Enter the following detail for the Queue resource:

Name: AsyncAuditController

JNDI Name: jms/AsyncAuditController

Bus name: select the previously created BizAgiBus.

Queue name: select the previously created BizAgiQueueEvent.

 

WS_106_JMQ01

 

Click OK.

Both queues should appear listed in the queues table:

 

WS_106_JMQ02

 

Remember to click Save in order to apply the changes into the master configuration.

 

Activation specification.

Now we will create 2 activation specification definitions (one to be used by the asynchronous tasks in Bizagi and one for logging purposes).

To do this, locate the panel to the left to quickly click the Activation specifications link (still at the Resources section in the expanded JMS item).

Make sure you select the scope that includes your cluster (it should be listed as Cluster=[Cluster_name]).

 

 

To create the first Activation specification (for the asynchronous tasks in Bizagi), click New.

Keep the Default messaging provider and click OK.

 

NODEWS_JMS26_nocut

 

Enter the following detail for the Activation specification:

Name: AsyncControllerActivationSpec

JNDI Name: eis/AsyncControllerActivationSpec

Destination type: select Queue.

Destination JNDI Name: jms/AsyncController

Bus name: select the previously created BizAgiBus.

 

NODE_config11

 

Click OK.

You should see this specification listed in the table of activation specification definitions.

 

WS_106_JMA01

 

To create the second Activation specification (for logging purposes), click New and ensure you have selected the corresponding scope that includes your cluster.

Keep the default messaging provider and click OK.

 

WS_JMS26

 

Enter the following detail for the Activation specification:

Name: AsyncAuditControllerActivationSpec

JNDI Name: eis/AsyncAuditControllerActivationSpec

Destination type: select Queue.

Destination JNDI Name: jms/AsyncAuditController

Bus name: select the previously created BizAgiBus.

 

WS_106_JMA02

 

Click OK.

You should see both activation specification definitions listed at the table.

 

WS_106_JMA03

 

Remember to click Save in order to apply the changes into the master configuration.

 

Messaging for cache management

Bizagi has a data access component which relies on the JPA framework (Java Persistence API).

In this component, Bizagi uses EclipseLink for the persistence layer and it involves several cache heuristics oriented to boost overall application performance.

Therefore, it is important that the cache gets replicated into all of the nodes which make part of the cluster.

This is carried out by creating 2 Topic Factories and 2 Topics derived from those factories, as resources.

 

To create the Topic Factories, locate the left panel to click Topic Connection factories, found under the Resources section within the JMS item.

 

Make sure you select the scope that includes your cluster (it should be listed as Cluster=[Cluster_name]).

Click New to create this resource. Keep the Default messaging provider and click OK.

 

 

NODEWS_JMS26

 

Enter the following detail:

Name: ELEntitiesTopicFactory

JNDI Name : jms/ELEntitiesTopicFactory

Bus name : Select BizAgiBus as created previously for Bizagi.

Nonpersistent message reliability: Best effort nonpersistent.

 

Click OK. To create the second Topic Factory, repeat the above steps: click New to create this resource, keep the Default messaging provider and click OK.

Enter the following detail:

Name : ELRenderTopicFactory

JNDI Name: jms/ELRenderTopicFactory

Bus name: Select BizAgiBus as created previously for Bizagi.

Nonpersistent message reliability: Best effort nonpersistent.

 

Click OK.

Now to create the Topic, locate the left panel to click Topics, found under the same Resources section within the JMS item.

 

Make sure you select the scope that includes your cluster (it should be listed as Cluster=[Cluster_name]).

Click New to create this resource. Keep the Default messaging provider and click OK.

 

NODEWS_JMS26

Enter the following detail:

 

Name : ELEntitiesTopic

JNDI Name: jms/ELEntitiesTopic

Bus name: Select BizAgiBus as created previously for Bizagi.

Topic space: Select Default.Topic.Space

JMS delivery mode: Select Nonpersistent

 

 

Click OK. To create the second Topic, repeat the above steps: click New to create this resource, keep the Default messaging provider and click OK.

Enter the following detail:

Name : ELRenderTopic

JNDI Name: jms/ELRenderTopic

Bus name: Select BizAgiBus as created previously for Bizagi.

Topic space: Select Default.Topic.Space

JMS delivery mode: Select Nonpersistent

 

Click OK and then on Save to apply changes.

 

4.3 Shared libraries configuration

We will now configure shared libraries in WebSphere so that deployment of Bizagi is faster, and you also have the possibility to share common libraries to other applications.

To do this, browse to the Environment section, and click Shared libraries.

 

Make sure you select the scope that includes your cluster (it should be listed as Cluster=[Cluster_name]).

Click New to register a shared library. Keep in mind in this step we reference both of the 2 shared libraries:

httpclient-4.1.1.jar

httpcore-4.1.jar

 

For the shared library configuration, enter the following detail:

Name: httpclient

Classpath:

$<WEBSPHERE_HOME>/optionalLibraries/httpclient-4.1.1.jar

$<WEBSPHERE_HOME>/optionalLibraries/httpcore-4.1.jar

 

Notice you will need to edit the <WEBSPHERE_HOME> value, which refers to the path where Bizagi's configuration files are installed in your setup.

Ensure too you tick the Use an isolated loader for this library checkbox.

 

WebSphere85_httpclient1

Click OK and then on Save to apply changes.

 

 

4.4 Authentication and Bizagi system user

Configuring the default system user in Bizagi is strictly required and it needs to be done for the user called admon from the domain called domain.

Configuring the default administrator user is done directly at the node having the Deployment Manager (DM) profile.

 

To do so, access the administration console in your DM-profile node, and go to the Users and groups section, and click the Manage users link.

 

WS_Users01

 

Click the Create... button to register the admin user.

Enter the following detail for the new user (needs to be specifically the information below):

User ID: domain\admon

First name: Bizagi

Last name: Bizagi

Password: bizagi

 

WS_Users02

 

Click Create. WebSphere will notify the success in the operation, and you may click Close.

 

Once this is done, configure the authentication module through the administration console, by locating the Security section and going into the Global Security item.

These steps need to be carried out in every node of your cluster:

 

Tick the Enable application security checkbox and click Apply.

 

NODEWSauth1

 

Click the Security domains item at the Security section.

Click on the Copy Global Security.. button to register a new Security domain.

 

NODEWS_auth01

 

Enter BizagiDomain as the Name for the new Security domain:

 

WS_auth02

Click OK.

Click on the newly created Security Domain (BizagiDomain), which will appear listed:

 

WS_auth03

For its scope property, make sure that you tick the checkbox that corresponds to the cluster (it should be seen under Clusters as [Cluster_name]).

Do this by expanding the necessary items until you reach the cluster and see that it includes all your nodes (under the Assigned Scope section)

 

NODE_config001

 

In the Security Attributes section:

Expand the Application Security item. Ensure that the Enabled application security checkbox is marked (for the active Customize this domain setting).

Expand the JAAS System logins item, and click on the System logins link (for the active Use global and domain-specific logins setting).

 

WS_auth05

For this definition, click on WEB_INBOUND:

 

WS_auth06

 

Click on New to create a JAAS login module. Make sure you specify:

Module class name: com.bizagi.security.jaas.BizAgiLoginModule.

Authentication strategy: REQUIRED.

 

NODEWS_auth07

 

Click OK.

Notice that the new module will be listed as the last of the modules to be used with a preset order.

Click the Set order... button.

Through this option, ensure you list and reorder this new module as the number one module (by using the Move up button).

 

WS_auth09

 

Click Ok, and make sure that the BizAgiLoginModule is listed first in the WEB_INBOUND modules (with module order = 1).

 

WS_auth10

 

Back in the domain configuration, click Custom properties in order to add specific authentication parameters.

Click New to add a property having:

Name: com.ibm.ws.security.web.logoutOnHTTPSessionExpire

Value: true

 

Finally, click Save as well to apply the changes.

You may need to restart the server once this is completed.

 

Once you have completed these steps, make sure you configure the Scheduler service as described at Configuring the Scheduler in WebSphere.