Archive for November, 2013

Part of what I was developing for this sprint has been to check the permissions when attempting to change the owner of a task.

The commands

laurent@laurent-Aspire-5742:~/Projects/development/LapisServer/bin$ ./ -u laurent -p xxxxx -host localhost -port 12345
test [32bbae32-8944-4c31-b370-60024bf533b3]
	=>	4f480ffe-21a3-4d82-8697-436c2a9fa506 [pause [laurent] [070d3c83-d658-4c22-bc1a-7c4f83660b49] => Complete]
	=>	a12ded01-ce52-4cef-81b6-274954cf8443 [Another pause [laurent] [4ff04705-9818-4637-87dc-5080bc35a50e] => Complete]
	=>	5bbf56c7-10d0-4da7-b3e7-0dc99bccd751 [verify [sarah] [30bd0552-7c1b-4fb7-97ae-34923789e9ed] => Active]
		=>	finish
		=>	start subworkflow
	=>	eab0c785-f523-4fea-afbd-c9589dc73088 [hello [laurent] [fe69d6ad-10b5-4ec8-9f1b-def5fdaa9505] => Complete]
	=>	6dbf3510-aef9-4840-9bf8-3c30bc2930dd [subWorkflow [laurent] [f9c21bfa-fa9d-46ec-950b-88b9d367d6af] => Rejected]

The user task should have been completed by the user Sarah. I then issue the command to change the owner for the task to myself, but since I don’t have the permission to change the task ownership, the engine raises an exception:

laurent@laurent-Aspire-5742:~/Projects/development/LapisServer/bin$ ./ -u laurent -p xxxxx -host localhost -port 12345 -w 32bbae32-8944-4c31-b370-60024bf533b3  -t 5bbf56c7-10d0-4da7-b3e7-0dc99bccd751 -o "laurent"
Exception in thread "main" access denied ("" "wfchown")
	at Method)
	at fukoka.lapis.engine.workflow.remote.RemoteNode.setOwner(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at sun.rmi.server.UnicastServerRef.dispatch(
	at sun.rmi.transport.Transport$
	at sun.rmi.transport.Transport$
	at Method)
	at sun.rmi.transport.Transport.serviceCall(
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(
	at sun.rmi.transport.tcp.TCPTransport$
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(
	at sun.rmi.transport.StreamRemoteCall.executeCall(
	at sun.rmi.server.UnicastRef.invoke(
	at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(
	at java.rmi.server.RemoteObjectInvocationHandler.invoke(
	at com.sun.proxy.$Proxy5.setOwner(Unknown Source)
	at fukoka.lapis.client.clt.WFchown.main(

In order to succeed, I then edit the server policy file to grant the permission:

grant principal "laurent" {
    permission "shutdown";
    permission "wfchown";

The listing now gives me the ownership of the task

Related articles

I have had a comment about the licensing model of the workflow engine. Since I have put a lot of effort into it, I would like it to be paid software and not open source. These are early days yet so I may be persuaded otherwise yet if the community clamours for it.

There are 3 valid licenses that can be obtained:

  • a 30 days evaluation license: None of the features are restricted. The license is only valid for 30 days.
  • a Developer Server license: None of the features are restricted. The license is only for non-production systems.
  • a Production Server license: None of the features are restricted.

In order to obtain a license, please contact Laurent Picquet, CEO of Fukoka Ltd. at

Licenses are server restricted, port restricted and time restricted. Any of these restrictions can be lifted. For example, a license may be issued to be valid across all the servers in an organisation, or/and across any port on a server, or/and to never expire. Licenses issued for an organisation or individual entities cannot be shared with or resold to other organisations or individual entities.

The license information comes in 2 parts. One part is a license properties file (fukoka_lapis.lic), detailing what the license covers. The other part is a signature file validating the licese properties (fukoka_lapis.sig). Tempering with any of these 2 files will invalidate the license.

The server properties file must reference these 2 files (usually in the etc sub-folder of your installation) through the following 2 properties:

  • lapis.license.licenseFile
  • lapis.license.licenseSignatureFile
The server will validate the license upon startup. Below is an example license file fukoka_lapis.lic
#Fukoka Ltd.
#Sat Nov 30 06:14:29 GMT 2013
organisation=Fukoka Ltd.
Oooh, not so long ago I announced that version 1.0 of the workflow system was developed. Now, it’s the turn of version 1.1. In this version, we’ve separated the interfaces from their implementations into their own jar file. This way, they are easier to add to your project and you can start developing your own custom actions for your workflows.
This meant that you can compile your custom actions and jar them together. Once you have your own jar file full of custom code, you add it to the lib/ext folder and the workflow engine can now call your custom node actions!
I re-instated the authorisation mechanism I had started to develop a while back so that sensitive actions cannot be performed without proper authorisation – like shutting down the server! The mechanism uses JAAS. The next version will see other activities only permitted to named users, such as wfchown, which changes the owner of a task.
Finally, I have integrated the sub-workflow task into the core API (as opposed to having it as a custom node implementation). Sub-workflows modes can be synchronous (it waits for the sub-workflow to finish) or asynchronous (the node transitions straight away and doesn’t really care what the sub workflow instance is doing).
We had to clean a couple of events in the process so that it would work even after server restarts, but it does work.
I have planned Version 1.2. Promoted from the project backlog to this version are:
licensing: This server is not free software. I’d like to make money from it
wfchown permission: not everyone will be able to take tasks as their own from another user
Events cleanup: This will be continued
client for current user: the current user will be used to connect. The command line tools will then use this to reduce the number of parameters required


Multi-Threaded workflow system

Posted: 1 November 2013 in Java

I have just finished some touches on version 1.0 of the Workflow Engine and it already has a few good features to rival with even the best out there. Even if it needs lot of work to make it pretty on the front-end, the back-end API is resolutely quite impressive.

  • Authenticated: you must log-in to use the workflow engine,
  • Multi-threaded: each workflow arc creates a new thread, for true concurrency
  • User Tasks: the user is responsible for performing the activity, complete the task whereby the workflow transitions to the next set of tasks.
  • Programmatic tasks: Java classes can be executed by the workflow.
  • Event system: every action in the workflow creates an event. You can create custom event listeners and react as soon as an event is generated.
  • File persisted: every time  the workflow changes, the modification is written to a file (in XML format). When the engine is shut-down and re-started, user tasks can be resumed (programmatic tasks shouldn’t – there is a product backlog story to make some programmatic tasks resumable).
  • Sub-Workflows can be started enabling you to compartmentalise the processes. This is powered by the event system where the “parent” workflow listens to the sub-workflow to resume itself when the sub workflow is finished.
  • XML format graph definitions: dynamically create XML graph documents using XSL, in house Lapis executable XML documents, or Apache JellyBeans.
  • XML user repository with encrypted passwords (there is a product backlog story to enable LDAP)
  • A series of command line tools to start workflows, list workflow, change task ownership and complete tasks

Work will now start on version 1.1, featuring the following

  • Cancel workflows: a command line to cancel workflows. Workflows can be cancelled already with a workaround
  • API interfaces extracted to their own jars to be easily added to you own project. This is to create your custom actions (these are your workflows, they should perform your tasks)
  • Sub-workflows have so far been implemented as custom actions. They will be moved into the core API.
  • independent sub-workflow: the parent does not need to wait for the sub-workflow to finish before moving on. Both sub-workflow types will be implemented in the core API.
  • 3rd party API: place your jars in lib/ext and we can run your tasks.
  • There will also be a development effort to add more to the javadocs which currently are looking quite bare.

Please contact me if you wish to receive an update when version 1.1 is complete so that you can receive a development license to evaluate the product. I will try to post a video of the product soon.