Welcome to the Java Graphical Process Designer (JGpd) tutorial for GroveWare’s eXFORMA platform! This tutorial is designed as a starting point for users who are either new to workflow or users of other similar workflow products. This will help users to become accustomed to the features and functionality of the JGpd tool packaged within the eXFORMA application. This tutorial is designed as a read-along, so for best results we suggest printing a copy of and following along as you build your workflow.

GroveWare has integrated an advanced version of the Java Graphical Process Designer (JGpd) version 0.1.5 into its eXFORMA platform and customized the application and interface to support the design and use of forms within eXFORMA.

Getting Started!

JGpd is available for download directly through the eXFORMA interface. Any user with administrative rights can log into eXFORMA’s backend to download the workflow application. Within the administrative side of eXFORMA under the Admin Tab there is a System section which allows users to adjust preferences and customize their version of eXFORMA. This section also provides users the link to download the e-Workflow studio, the Java Graphical Process Designer.


Selecting the link ‘e-Workflow & e-Xform Studio’, will provide a download interface similar to the one pictured below. ‘Click to Download’ the e-Workflow Studio, saving the file called jbpm.jar to your desktop or another location of your choosing.


There is no setup required, so when the download is complete, you’re finished. You have successfully downloaded and installed the Java Graphical Process Designer to your system and it is now available for you to use. Locate the file on your system and double-click it to run the application, you are now ready to create your first workflow.

The Java Graphical Process Designer Interface

Before we start building our first workflow, take a few minutes to familiarize yourself with the application interface. The JGpd interface is broken into 3 main components; the toolbar, the graph window and the element properties window.


Upon closer inspection, you should notice that the toolbar is composed of some common elements that you can find in other applications, such as:


New, Open, Save, Print, Undo, Redo, Cut, Copy, Paste, Edit, Find, Scale, Zoom-In and Zoom-Out.

The toolbar is also comprised for some less common elements that we will review now.


Process Start Object, Process End Object, Activity Object, Decision Object


Process Split Object, Process Join Object, Transition Object

We will review each of these objects in depth later, for now it is important to just identify what each of these objects are.

Building a Workflow

Select ‘New’ to open a new workflow graph. We will start by assigning the Process Properties to this graph. Select ‘Process Properties’ from the ‘Process’ menu.


Start by assigning values to the ‘Name’ and ‘Description’ properties. These values should be intuitive so that another user reviewing your graph is able to understand the purpose and function of the workflow. Assigning a value to the ‘Responsible’ Property can also help to further explain your process and which department or users are responsible for completing it – this is a required field, but has no function other than to aid in the process description. An example of good technique is as follows:


The second task in starting a new graph is to assign the attributes ie- forms and text to the graph. Before we do this we need to make a decision about our process. Is our workflow going to start after an event like the submission of a form for approval, or will our workflow operate on a scheduled interval like a survey which is distributed every Friday? Attribute inputs only need to be assigned for dependent workflow; that is a workflow which is dependent upon another action, ie- the submitting of a form, in order to initiate the process. So if we are going to schedule our workflow to occur at a specific known time, then completing the Attributes Input is only necessary if we need to add additional forms to the process.

Select ‘Attribute Input’ from the ‘Process’ menu.


Select ‘Add’ from the ‘Attribute Input’ window and a new line will appear for you to enter your inputs. The first input for a dependent workflow should be ‘form-start’. ‘form-start’ is a pre-defined attribute assigned to the form which will be used to initiate this workflow process and is always of the type ‘form’ and has no initial value. For a scheduled workflow, only add attributes if needed and never a ‘form-start’.

For demonstration purposes we have added a second form with the name ‘form2’ with type ‘form’ and an InitialValue of ‘$formId=756;’ which is the eXFORMA id for the form we are going to use in our workflow. For assistance in finding the formId number of the form for your process, please refer to the eXFORMA user manual. You can also set the form’s name as it is to appear during the workflow. The form name can be set placing the script $formName= Name of Form right after the formId script (using a semicolon to separate them).

Combined, the formId and formName field should look something like the following:

eg. $formId=756; $formName=Event Form

It is also important to note that you cannot use any special characters in the Name or InitialValue so characters such as ! @ # $ % ^ & * ( ) _ – + = [ ] { } \ / | ; : < > , . ? are all off limits and will result in errors.

Note the attribute name can not be the same as the name of a role in the process. This causes an error in the system because both attributes are filed to the same table in the database.

Building a Workflow Graph

Start building your workflow graph by adding a ‘Start Object’ activity. This is the first step of our workflow process. The start object is the trigger which initiates the workflow. Give it a name (conventionally we use ‘Start’ as a value); but you can name it whatever you like and then add a description of the first step.

Assigning a role here is very useful, as the user who completes this task can be referred to later on in the process and have tasks assigned back to them. The role who initiates the workflow is assigned the Actor value and tasks can be assigned back to this initiator by assigning them to the ‘Actor’ field of other future activities. We will see how this works as we look at the Activity objects a little later on. Make sure to Click the ‘Apply’ button when you are finished to assign your values to the properties.


If the process is dependent upon a form as we discussed earlier then we will also need to assign the form value under the ‘Fields’ tab. Select form-start as this is our starting form and select the user access. In order to complete the form, access will need to have the read-write ability, so please be sure to have this as the access level. Again be sure to select ‘Apply’ to assign the values when you are finished.



If the workflow is to be scheduled by eXFORMA and not initiated by a form submission than a form attribute does not need to be assigned and this step can be skipped.

The Decision Object

Decision points are one of the key activities to a workflow, they are intelligent nodes that dictate which path the process will take; and essentially give the workflow its brains. They are also one of the easiest objects to create and use in JGpd.

Select the ‘Decision Object’ and add it to your process. Assign a Value to the Name property of the object and click ‘Apply’. The next step is to add a transition arrow from our ‘Start’ object to the decision point. Select the ‘Transition Object’ and select the ‘Start Object’ this will be the beginning point of our transition. Then select the ‘Decision Object’ this will be the ending point of the transition.


Now we need to determine what will happen next in our process so we know how to transition out of the decision point. In this example we will be displaying a form to the user, based on the decision they made in form-start. So let us take a minute to define the process. We are going to make a decision based on some value that we will reference in the original start form (green start node with form-start assigned to it) – depending on the value selected by the user, we will decide whether to follow one path or another from the decision point.

This is what the process would look like in JGpd.


So first we will just add two ‘Activity Objects’ to our graph and the ‘Transition Objects’ from the ‘Decision’ to the ‘Activity’. Now we will define the transitions.

The Transition

Transition’ objects can be defined in two ways, the first is as a condition when they are coming from a decision point and the second is as a status marker when leading to an activity. In this example our transition objects meet both conditions. So we can define them in both ways.

First select the arrow on the graph. A display field will prompt you for text entry. In this display field enter the condition based on the decision point. Conditions are entered in the form of:  globalID.reference = value

Some examples:

  • = Yes
  • = No
  • = 1
  • <> 1
  • form-start.eventType = ‘Board Meeting’
  • request.leaveType = ‘Banked-Over-Time’

Note the condition statement as well as the reference and value are all case sensitive, so make sure to verify your entry with the actual values on the form.


Next we will define the status of the transition object. The status property is displayed below the graph in the graph elements properties window. The value entered into the status here is what is displayed by the workflow in eXFORMA when leading to the next task. These values are limited to 20 characters, and they can help to serve as a reference as to where the workflow is pointing when looking at the process within the eXFORMA environment. These statuses only work when the transition is leading into an activity object, because the activity object requires an external input in order to move forward and the status property describes the input required to the user.

The Activity Object

In the previous step we created two Activity Objects called Form1 and Form2 so that we could assign transitions from our decision point. Now we will look at these activity objects and define their Properties.

You should recognize this first screen by now; simply enter values for Name, Description, and Role.


The Fields tab decides which form is attached to this activity object. Click ‘Add’ to insert a Field property. From the Attribute list select the form that this Activity applies too. A list of all the available forms that were created in the Attribute Input section earlier will be available to you. Select the form you wish to use and then set the access level to read-write.


The next step is to set the Activity Policies.  There are two types of actions associated with the Policies tab; Build-in Action and External Action. The ‘Build-in Actions’ are common predefined actions which signal that the activity has been completed and to move it along to the next step of the workflow. Selecting Completion Form is the most common action, as it signifies that the workflow should proceed to the next step once a form has been completed and submitted.

You also have the opportunity here to call an external action. External Actions are based on any external class you may have defined in the ‘External Class’ item of the ‘Process’ Menu. There is section a little later on in this guide which covers external classes in more detail, including their definitions. To include an external class in this activity, first you should select ‘Build-in Action’ as External Action, then type in the path in which the external class will be found within the eXFORMA structure. This is usually in the following format:  com.GroveWare.webapp.action.className.


The next tab is the parameters tab, which changes its properties depending on the ‘Build-in Action’ you selected under the Policies tab for the activity. For Completion Form action, the parameter displayed is snooze, which is not being utilized by eXFORMA and can be ignored.

The Actors tab is used to assign the activity to a user. There are multiple ways to assign activities to users since JGpd supports eXFORMA groups, roles, users and JGPD actor assignments.

Assigning the activity to a group can be done by inputting the group name as the value corresponding to the ‘Assign to Group’. Assigning the task to a group makes it available to be completed by any user in the group. The process does not care which user completes the task, as long as one of them does. This is ideal for workpool situations. When one of the users in the group accepts the activity by selecting it from their task list and submitting the form, then it is no longer available to anyone else in the group and the process continues. For the names of groups, use the eXFORMA administrator section to browse the existing categories or create your own new group.


Assigning the activity to a role is identical to assigning it to a group. Just input the value for the Role and the task will be made available to any user, in any group occupying the specified Role. Again the process does not care which specific user completes the task, as long as one of them does. You can learn more about Roles by reading the eXFORMA user guide.


The next option you have is to assign the task to a specific user. There are two ways to assign users which conveniently can also work for groups, and roles; assign the name directly or provide a reference to the name. Assigning the User directly requires you to enter the eXFORMA username of the user that the task will be assigned to. For instance if you want to assign the task to the user named Ed Smith with the eXFORMA username esmith, then just enter esmith in the value for User in the table.

The second option is more dynamic – JGpd allows you to assign the user through a reference on a form. Similar to the way we entered the conditions on the transition objects, we can enter user conditions in the table. Entering a reference can be broken into 3 parts. Attribute Input Type, Attribute Input Name and the XML reference. It is entered in the form of:


The easiest way to figure out the assignment is to work backwards. Ask yourself where in the process is the user name available to me? Is it being selected via a pulldown menu or checkbox? It is being entered via a textfield? Or am I assigning it based on some other selection criteria?

For this example it is coming from the user selection in a pulldown menu. The reference for the pulldown menu is global/myForm/assignToUser. The field that is referenced is in form-start where form-start is of type form. Therefore the assignment would look like this:


Another way of assigning the task is by using the Actor. The actor value would correspond to the Role property of the Properties Tab of one of our Activity Objects. In this way a user who we may not know from a group, which completed the original task, can be assigned the Role and then called upon to complete corresponding tasks later in the process.


The Process End Object

It is required that all processes have an end and that ending is marked with the Process End Object.

The end object is just a visual marker that says the process is over. It serves no function other than to end the process. You can only have 1 start object and 1 end object in each process. And it is important to note that in spite of the End Object being reached by one stream of a process, the process will not end until all streams are completed. So it is very important to assure that all of the splits and paths that have occurred in the workflow eventually reach the end point in order to complete the process.


External Classes 

More complex workflows often require external classes to complete the tasks required of it. In order to insert an external class into the workflow, you must first define the class name, path to the .class file, and path to the .java file. This is done from the Process à External Classes menu.

The class name is written in the following format: com.GroveWare.webapp.action.className

This class name is what you will use to reference the external class from an activity object under the Policies tab. The class file and java file columns are to specify the path of the .class and .java file of the external class, respectively. An example can be seen in the screenshot below.




Contact Form Powered By :