Standard WebSphere configuration

<< 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 >

Standard WebSphere configuration

Overview

When using Bizagi Engine in a JEE platform, your processes can be configured to run in different JEE Application servers, such as WebSphere, WebLogic, or JBoss.

The configuration procedure for each Application Server to work with Bizagi, may slightly vary according to each server's differences.

 

This section focuses in WebSphere configuration to work with Bizagi, meant for a Test or Production environment and as a standalone instance (no load balancing).

 

Bizagi_WebSphere_standard

 

 

If you wish to setup your WebSphere in a high availability schema and use load balancing, refer to Clustered WebSphere configuration.

 

 

Note that for the Development environment (Bizagi Studio), no configuration steps are required given that Bizagi JEE Edition installs a bundled JBoss Server which is automatically configured.

Using the bundled JBoss in the Development environment will promote agility in the project's implementation (given that JBoss is light-weight, it will start up or restart faster, and it will not require additional/manual configuration).

However, if your project strictly needs to use WebSphere in the Development environment, follow the steps described below as well.

 

 

Prerequisites

To configure your WebSphere Application Server in a Test or Production environment, the following are required:

Installed JAVA SE's JDK. It is strongly recommended to use JDK 7.

JAVA_HOME environment variable properly configured (it is recommended that this path contains no spaces).

 

JavaHome

 

Have at hand the configuration and deployment files delivered by Bizagi (BizAgi-ear-Websphere-dist.zip).

It is required that this BizAgi-ear-Websphere-dist.zip (provided when downloading Bizagi Engine JEE WebSphere) matches the version you used in your development environment (i.e Bizagi Studio's version and JEE Plugin).

Installed WebSphere Server v 8.5.5.

The supported version of WebSphere is 8.5.5, which includes up to the 8.5.53 update (recommended).

Similarly, an installed WebSphere Application Server Network Deployment (WASND) which supports and matches the WebSphere server version v 8.5.5.

WebSphere Server can be downloaded and requested from the official IBM webpage.

Make sure that you select the appropriate installer for your system, that your system meets the requirements recommended by WebSphere, and that you follow the guidelines in the section about Requisites to use WebSphere and WASND.

 

 

WebSphere requisites

To install WebSphere (once its prerequisites are met), make sure you consider the following:

 

Installing the usual set of files and products featured by WebSphere to manage your WebSphere server as recommended.

The set of files and products include installing: Installation Manager, WebSphere Network Deployment, and necessary WebSphere Fixpacks (in this case, Fixpacks for version v 8.5.5).

 

note_pin

When installing Installation Manager consider:

Choosing an installation directory that does not contain blank spaces.

Having already uncompressed media files of the WebSphere Network Deployment and WebSphere Fixpacks, each into a separate and predefined directory that does not contain blank spaces.

 

WebSphere85_02prereq

 

Setting two repositories for the Installation Manager, by defining the paths from which files will be taken for the product's use.

The 2 added repositories should refer to the predefined directories where WebSphere Network Deployment and WebSphere Fixpacks were extracted.

 

Installing the WebSphere Application Server through the Installation Manager.

When doing so, follow the same recommendation mentioned above, of choosing an installation directory that does not contain blank spaces.

Choose a directory to install packages of shared components, that does not contain blank spaces as well.

Note you may start the Profile Management Tool to create a required profile for your WebSphere Application Server.

 

WebSphere85_01prereq

 

 

Use the Profile Management Tool to create a profile with the following characteristics:

oHaving Environment set to Application server (recall that this procedure configures WebSphere for a standalone configuration, and not for a clustered setup).

 

WebSphere85_03prereq

 

oIncluding the option to Deploy the administrative console. This option is available by first selecting an Advanced Profile creation:

 

WebSphere85_04prereq

 

oSetting a profile name and a profile directory that does not have blank spaces.

 

oSetting a Node name and a Server name that does not have blank spaces (and using the only allowed characters).

For the Host name you may leave the default, usually taking up the physical server's name.

 

oEnabling the Administrative security and specifying a user and password for authorized access.

 

WebSphere85_08prereq

 

You may disregard the configuration related to Security Certificates (by leaving the default values) and the port values assignment.

 

oNot setting the server as a Windows service (for Windows OS), by making sure the Run the application server process as a Windows service is left unmarked.

 

Proceed once you review the details in the installation summary.

This installation path, including the server instance will be referenced as your <WEBSPHERE_HOME> from this point on.

 

 

WebSphere options

For information about how to start, stop or acesss the administration console in WebSphere, refer to the information below.

 

 

Starting the Server (domain)

To start WebSphere services, execute the following file in a command prompt:

 

In Unix-like operating systems:

<WEBSPHERE_HOME>/profiles/AppSrv01/bin/startServer.sh [server_instance_name]

 

In Windows OS:

<WEBSPHERE_HOME>\profiles\AppSrv01\bin\startServer.bat [server_instance_name]

 

Consider:

[server_instance_name] should match the name of your WebSphere Application Server instance as configured during installation.

 

WebSphere85_09prereq

 

Stopping the Server (domain)

To stop WebSphere services, execute the following file in a command prompt:

 

In Unix-like operating systems:

<WEBSPHERE_HOME>/profiles/AppSrv01/bin/stopServer.sh [server_instance_name]-username [authorized_user] -password [authorized_password]

 

In Windows OS:

<WEBSPHERE_HOME>\profiles\AppSrv01\bin\stopServer.bat [server_instance_name] -username [authorized_user] -password [authorized_password]

 

Consider:

[server_instance_name] should match the name of your WebSphere Application Server instance as configured during installation.

[authorized_user] should match the username set for administrative security as configured during installation.

[authorized_password] should match the password of the user set for administrative security as configured during installation.

 

WebSphere85_07prereq

 

 

Accessing the Administration Console

To access the Administration Console of WebSphere, enter the following address in the browser of your choice.

https://localhost:9043/ibm/console/logon.jsp

 

 

 

What you need to do

To configure WebSphere to work with Bizagi, the procedure is carried out:

 

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 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

Use the names involved in references and configuration exactly as presented below, keeping in mind that such configuration is 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 your process deployments.

 

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>

 

 

 

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.

 

WSphere_1_01

 

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_JVMarguments2

 

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), and this time, click the Custom properties link in order to create 3 custom properties.

 

WSphere_1_06

 

Click the New button to create the first custom property.

Name this 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).

This folder is located inside of <BIZAGI_HOME>.

 

WebSphere85_bizagiconfig

 

Click Ok.

Click the New button to create the third custom property.

Name this property as com.ibm.websphere.webservices.soap.enable.legacy.get.behavior, and specify that its value is set to true.

Click on OK, and ensure that you click Save to apply these changes.

 

You may see the newly properties listed as shown below:

 

WS_106_bizagiconfig02

 

Restart the server once this is completed.

 

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.

Select the scope including the server (should be listed as Node=[your_Server_Name], Server=server1):

 

WSDA_01

 

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

 

WSDS_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, it will appear listed in the table of Providers (either Oracle or SQL Server).

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

 

WSDA_04

 

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).

Select the scope including the server (should be listed as Node=[your_Server_Name], Server=server1):

 

WSDS_01

 

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

 

 

WSDS_02

 

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 in the following Windows (until you reach the last guided step and click Finish to create the Data Source).

No further configuration is required for this Data Source in Bizagi when using SQL Server, and you may leave the defaults shown by WebSphere.

 

If you are using Oracle, click Next and in the upcoming step, make sure that you edit the 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 .

Once this is set for your Oracle connection, click Next in the following Windows (until you reach the last guided step and 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.

 

WSDS_04

 

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.

 

WSDS_05

 

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

 

For Oracle:

owebSphereDefaultIsolationLevel: Set it to 2. This 2 value will indicate READ-COMMITTED level.

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

ouser: The user schema which represents your Bizagi project.

opassword: The password to access the user schema.

 

 

WSDS_06ora

 

For SQL Server:

oserverName: The Database Server name.

oportNumber: The port under which the Database service listens. In SQL Server, by default it is the 1433.

owebSphereDefaultIsolationLevel: Set it to 1. This 1 value will indicate READ-UNCOMMITTED level.

odatabaseName: The name of the Database of your Bizagi project.

ouser: The login account to access the Database.

opassword: The password for the login account to access the Database.

oresponseBuffering: 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.

 

WSDS_06sql

 

 

 

 

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

You need to restart your WebSphere service.

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:

 

WSDS_07

 

 

4.2 Messaging service configuration (JMS)

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

To do this, access the administration console, and go into the Service integration section and click Buses.

 

WS_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 your server instance is selected in the Server property (from the drop-down list values).

 

WS_JMS05

 

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

 

WS_JMS06

 

In the following 2 steps, you may click Next and leave the default values.

No additional configuration is required for the file store, and these settings may be later reviewed and tuned by the Application Server administrator.
Click Finish to create the first bus member.

 

Destination resources

Back in the bus information, we will create 2 queues for Bizagi to handle asynchronous capabilities (one for asynchronous tasks and one for logging purposes).

 

To create and associate the first queue (for asynchronous tasks), click the Destinations link (under the Destination resources section).

 

WS_JMS07

 

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 from the drop-down list:

 

WS_JMS10

 

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:

 

WS_106_JMS03

 

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.

Select the scope including the server (should be listed as Node=[your_Server_Name], Server=server1).

 

 

WS_JMS13

 

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

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

 

WS_JMS15

 

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

Enter:

Name: AsyncControllerFactory

JNDI Name: AsyncControllerFactory

Ensure you select the bus created for Bizagi (BizAgiBus).

 

WS_JMS16

 

Click OK.

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

 

WS_JMS19

 

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

 

WS_JMS20

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

 

WS_JMS21

 

 

You will be directed back to where yous see this factory listed under the queue connection factories table.

 

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

 

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:

Name: AsyncAuditControllerFactory

JNDI Name: AsyncAuditControllerFactory

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 resources.

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).

Select the scope including the server (should be listed as Node=[your_Server_Name], Server=server1) to filter the JMS providers:

 

WS_JMS17

 

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

Keep the Default messaging provider and click OK.

 

WS_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.

 

WS_JMS23

 

Click OK.

You should see the recently created Queue at the table.

 

WS_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.

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).

Select the scope including the server (should be listed as Node=[your_Server_Name], Server=server1):

 

WS_JMS25

 

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

Keep the default messaging provider and click OK.

 

WS_JMS26

 

Enter the following detail for the Activation specification:

Name: AsyncControllerActivationSpec

JNDI Name: eis/AsyncControllerActivationSpec

Destination type: Queue.

Destination JNDI Name: jms/AsyncController

Bus name: select the previously created BizAgiBus.

 

WS_JMS27

 

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.

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: 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.

 

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 server's instance (for this case, a standalone server).

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 internal system user in Bizagi is strictly required and it needs to be done for the user called admon from the domain called domain.

To configure the default administrator user, access the administration console and go to the Users and groups section, and click the Manage users link.

 

WS_Users01

 

Click the Create... button to register the internal system 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.

 

To configure the authentication module, go to the Security section and into the Global Security item.

Mark the Enable administrative security checkbox and click Apply.

 

WSauth1

 

Go to the Web and SIP security section and click on the General Settings link.

 

WSauth2

 

Under the Web authentication behavior section, make sure that the Authenticate only when the URI is protected radio button is selected.

 

WSauth3

 

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

Click the Security domains item at the Security section.

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

 

WS_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 properties, make sure you mark the server's instance checkbox (server1).

Do this by expanding the Node, [your_server], and Server items (under the Assigned Scope section)

 

WS_auth04

 

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:

com.bizagi.security.jaas.BizAgiLoginModule as the Module class name.

REQUIRED as the Authentication strategy.

 

WS_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

 

Finally, click Save as well to apply the changes.

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

 

 

What is next?

After finishing these steps, your WebSphere installation is configured to work with Bizagi Processes!

You may now startup you server and generate the Bizagi Work portal (by having your Bizagi Processes deployed as a WebSphere application).

 

note_pin

Recall that now that your WebSphere server has been set up to work with Bizagi, the path and files located at <BIZAGI_HOME> should not be deleted nor modified (unless when upgrading your Bizagi version in which case, some specific modifications to such files may apply).

Other input files not used in the above steps such as BizAgiConsoleManager-JEE-dist will be employed specifically by the Processes deployment procedure and you may as well uncompress the JEE Console folder inside of <BIZAGI_HOME> (recommended).

 

For more information about this option, refer to deploying the application into WebSphere Application Server.