Lombardi Notes 03dec2008
Notes from dec 3, 2008
continuing from day2
Using a rule service within an action to determine value for decision gateway
Since gateways only allow testing of a single condition for a given outbound flow line, we need another way to test multiple conditions before reaching the gateway. We can use an action before the gateway to collect data and run the condition checks we need, then use that same service to set a local boolean (or some other simple value) as the final result of all tested conditions. That boolean is then tested in the gateway to determine if a given outbound line should be followed. Here is how we can set that up in teamworks...
In the services folder, create a new rule service (right click->new->service->rule service). Drag in a single rule and add flow from start to end.
Perform variable mapping in the rule. Input variables will be passed from the process to the service, then we'll define a single output variable (boolean) to pass back to the process.
Then select the "rules" tab. You can add input variables as columns using the + button, you then set conditional rows with values to test against those columns. Note that "Action Requirement" is only a comment, it has no functionality.
Save the new service, then we need to apply it to the process BPD. Assign the rule service to the action before the decision dimond thing. Map the boolean variable from the service to the local private variable (you have to define that as a variable in the process too). Now when you run the process, you can see the token pause at the rule service to check the value. You can inspect the variable and continue to debug from there.
Morning challenge
For the weather check and ride home process, we now add in a coach to collect the data to termine what path to take. I chose to collect all the data in one coach at the start using boolean values within my own weather data type. I then test the boolean results in decision gateways throughout the process. [Download a teamworks export of this challenge]
Pulling dropdown list values from a database table for access in a coach
Connectors
- connectors are methods
- can pull from a datasource into java or web services
1 - Create a database connection in jboss for access from jboss web applications
- JNDI datasource
2 - Create a database connector (service)
- Choose the javaclass that defines the connector (not covered in class how to build that class)
- use the discover button to read methods and vars used in the class and expose them via the connector
3 - Create integration definition (service)
- reads the connector method and allows access to input/output from that.
you can then test the connection via the "test" link in the integration definition
4 - create wrapper service that will call the integration definition and allow us to manage all our go via a standard service.
- drag integration definition from the folder tree directly into the diagram view of the service. hook up flow connetor lines from start to end.
- setup input/output variables to match the integration definition.
5 - Go back to the Integration service and do variable mappings by hand. Input variables need to have the default values set to the "hash" value of the param passed in. The notation is something like "<#=tw.local.myvar#>". The output var is mapped by its standard name without the hash goo.
6 - create yet another service that will now get our data for the department dropdown list
- drag in the sql execute service
- map variables to the sql execute service. use the automapping and allow it to create private vars.
- drag in a server scriptlet item (or server script item. If you use a scriptlet, be sure to bind it to a variable!) to build a sql string you can pass in to the sql execute. implementation = " SELECT departmentName, departmentCode FROM departments "
- drag in a server script item to build the dsn. implementation = " tw.local.dsn = "jdbc/TrainingDB"; "
- Now debug the service and see if it works
Note that using this method still simply ends up creating a string SQL statement that gets passed to the server. This example does not cover bindparams to the database at all. I think bindparams are supported in JDBC, so you should be able to build in support via the classes using the method here.
7 - now add another server script block in order to map the xml results to a javascript list array of key value pairs.
8 - Update the coach service to use the get department list
-now go back to the coach service and drag in the "get department list" service. Connect it to the flow before the coach runs, then setup variable mapping so that the department list variable is passed into the coach service as shown below (using automapping)
- now go and update the coach form to use the new list. Modify the department list field, delete any manual values set, then enable dynamic data via a list variable. Select the department list variable you just defined. The image below gives you an idea of whats expected for the bindings.