Set up our users

By default, jBPM is set up with a few test users who happen to be characters from Sesame Street: Ernie, Grover, and so on. Unless we want to give our brave testers a complex, we had better set them up with some proper usernames for the system. Of course, these usernames have to have a correspondence with the swimlanes that we used in the previous chapter to assign tasks. The relationship is one of "users" belonging to "groups" and it is modeled in the database that underpins jBPM. The behavior we are looking for is that when Jack Thompson, who is a Talent Scout, logs into the web console, he should see tasks in his task list relating to "Hold auditions", as he fulfils the swimlane criteria for that node in our process definition. We can set up new users by copying in our group and user information to the pre-existing database tables.

We don't need to set up every single user in the organization right now, only those people who will be helping us out with testing our proof-of-concept system. We'll need at least one user for each type of swimlane. We'll give our users suitable, system-ready usernames, without any spaces or non-standard characters: this will make the upgrade path to fully integrate with a Windows domain easier in the long run. One consideration we do have to bear in mind: at run time, we won't know who some of our users will be, as they are actually defined during process execution. For example, we don't know who our band members are going to be until we've held auditions and selected the band. We can get round this by simply creating anonymous logins that whoever gets picked can use.

For our purposes, we'll set up the following groups and users:
• Talent scout — powellb
• Legal adviser — rumpoleh
• Band member — memberb
• Record producer — dredr
• Artist development — harrisr
• Songwriter — lennonj
• Musician — hendrixj
• Video production — welleso
• Artist — monetc
• Administrator — admin
• Manager — manager
In order to insert these users we need to get the database running. Start the JBoss application server with the shortcut we created in the last chapter. Once the application server has finished its start up routine, open up your web browser and go to http://localhost:8080/jmx-console/:

This is the management console that comes with the JBoss application server, which provides some utilities for managing it, including a simple database utility. We'll use this database utility to make the changes that we need. The database used in the default jBPM installation is called Hypersonic: it is a perfectly reasonable database for testing out jBPM on our local machine, although, in a later chapter, we'll see how we can swap it for a more robust database when we want to use our BPM system in anger.
In the JMX Console, under the jboss heading you will see a link entitled database=jbpmDB, service=Hypersonic: click this link. Scroll down the next page until you get to a line called void startDatabaseManager(). Click the Invoke button directly underneath. You will go to a new screen and after a few moments' delay the HSQL Database Manager will start:

On the left of the Database Manager, you can see the list of all the database tables used by jBPM. The tables we are interested in are PUBLIC.JBPM_ID_GROUP, PUBLIC.JBPM_ID_MEMBERSHIP, and PUBLIC.JBPM_ID_USER. If you want to see the existing contents of these tables, you can type this simple bit of SQL into the cursor window at the top and click Execute SQL:
SELECT * FROM PUBLIC.JBPM_ID_GROUP
This will bring back the list of groups that are already set up in jBPM. As you can see there are five columns in the table: ID_, CLASS_, NAME_, TYPE_, and PARENT_. We won't linger over the meaning of these columns; suffice it to say that the values in these columns define the relationships between the database tables that manage jBPM users. We need to add our own groups in, and again, we do this by running a bit of SQL on the database. You can either type the following in yourself or copy and paste in the code from the insert-groups.sql file that is in the code download for this chapter:

/*First we add in the security roles*/

INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (301,'G','manager','security- role',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (302,'G','participant','securi ty-role',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (303,'G','administrator','secu rity-role',NULL)

/*Then we add in the organisations*/

INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (201,'G','Talent scout','organisation',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (202,'G','Legal adviser','organisation',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (203,'G','Band member','organisation',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (204,'G','Record producer','organisation',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (205,'G','Artist development', 'organisation',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (206,'G','Songwriter','organisation',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (207,'G','Musician','organisa tion',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (208,'G','Video production','organisation',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (209,'G','Artist','organisati on',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (210,'G','Administrator','orga nisation',NULL)
INSERT INTO PUBLIC.JBPM_ID_GROUP VALUES (211,'G','Manager','organisat ion',NULL)

After you click the Execute SQL button, the Database Manager should come back with confirmation that the new groups have been added:

If you run the SELECT * FROM PUBLIC.JBPM_ID_GROUPPUBLIC.GROUP command again, you will see that our new groups are now in the table:

Now we need to do another insert for our new users:
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (101,'U','powellb',' ','powellb')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (102,'U','rumpoleh',' ','rumpoleh')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (103,'U','memberb',' ','memberb')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (104,'U','dredr',' ','dredr')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (105,'U','harrisr',' ','harrisr')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (106,'U','lennonj',' ','lennonj')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (107,'U','hendrixj',' ','hendrixj')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (108,'U','welleso',' ','welleso')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (109,'U','monetc',' ','monetc')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (110,'U','admin',' ','admin')
INSERT INTO PUBLIC.JBPM_ID_USER VALUES (111,'U','manager','manager@ bland.com','manager')

Again, you can either type in the command yourself or use the insert-users.sql file in the code download. Finally, we have to link our users to our groups through the PUBLIC.JBPM_ID_MEMBERSHIP table. We need to define all our users with a security role of "participant". In addition, our Administrator is given security roles of both "administrator" and "manager", and our Manager has a security role of "manager". We also need to assign each user to the swimlane groups that we have just added to the database. We do this by adding in new rows to the PUBLIC. JBPM_ID_MEMBERSHIP table, specifying the relationships between the rows in the PUBLIC.JBPM_ID_USER and PUBLIC.JBPM_ID_GROUP tables. We link the two tables' ID fields together: if you have deviated from the standard installation in any way, you will have to edit the following SQL to get the relationships right as specified above:

/*Then we make all our normal users participants*/

INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'101 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'102 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'103 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'104 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'105 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'106 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'107 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'108 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'109 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'110 ','302')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'111 ','302')

/*Then we make the administrator an administrator*/

INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'110 ','303')
/*Then we make the manager and the administrator a manager*/
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'111 ','301')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'110 ','301')

/*Finally we add all our users to their organisation groups*/

INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'101 ','201')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'102 ','202')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'103 ','203')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'104 ','204')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'105 ','205')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'106 ','206')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'107 ','207')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'108 ','208')
INSERT INTO PUBLIC.JBPM_ID_MEMBERSHIP VALUES (NULL,'M',NULL,NULL,'109 ','209')
Phew, thankfully that's done, our proof-of-concept users are set up and ready to go. We can now safely close the Database Manager.

Deploy the process and user interface
Let's now deploy our process definition and console task forms to the server, so we can have a play around with them. First, start the application server again, if you closed it after the database changes we just made. Next, in the Designer, switch to the Deployment tab of the main editing window. You will be presented with a list of all the files that are available for deployment to the application server :

Make sure that all of the files in the left-hand pane are checked: by default, the files in the right-hand pane will be unchecked and we can leave it that way for now. In later chapters, we'll see how to deploy Java classes and resources through the right-hand pane. Scrolling down, we can see that we also have the opportunity here to specify the URL of the application server to which we should deploy our files:

It shouldn't be necessary to change the settings here, although, it is worthwhile clicking the Test Connection button to make sure the Designer can connect to the application server without any problems. If all is well, click the Deploy Process Archive button to deploy our files to the application server. This is all we need to do to put our process live.
One nice little feature of jBPM is that the engine is smart enough to keep track of the versions of our process that we deploy, without us having to manually provide version numbers or worry about overwriting previous versions of the process. For example, if I open up the Database Manager again and look in the PUBLIC. JBPM_PROCESSDEFINITION table at the versions of our "Produce music products" process that I have deployed to the application server I can see eight versions:

Every time I click the Deploy Process Archive button, a new version of the "Produce music products" process is added to the end of this table.