Liferay Integration


I have found some info on integration with Liferay (and watched a long video).

But I am not sure where to really start. Currently I have played with adding the web gui as an iframe, and considered using some shared authentication, but that is about it.

Are there any pre-made portlets or starting points that anyone knows about?


Hi Colin,

I don’t know Liferay, but the usual way to augment the webapps or add new features would be plugins. Could you describe your use case in a bit more detail?


Hi Colin.

It depends on what you mean by “Liferay Integration”. Typically Customers using a portal (e.g. Liferay) develop portlets (themselves!) being embedded into their portlet. Typically this is limited to Tasklist/Taskforms as this is exposed to all users. That means you “only” use Camunda as an Engine and leverage the API to communicate with it. UI is build in whatever technology you prefer within Liferay (customers I know typically use JSP or JSF).

Often Cockpit is used beside the Portal, as only limited numbers of users need to access it (and you could still develop your own IdentityService to Authenticate against Liferay).


Thanks Bernd,

I was just checking that there was no generic portlet available already.

The functionality would probably be broken into a couple (or more) portlets:

1: A portlet to display the initial form. Guess this would need to use the calls as mentioned by Sebastian in my earlier post.
2: Optionally (if we did not use the task list or Camunda as is), a portlet(s) to display the tasks that you have created and/or are assigned/available (etc, and some way of interacting with them).

Is the general recommendation to use the rest API for this sort of thing, or is deploying Camunda into the Liferay instance the way to go?

If there are no portlet examples available, is there any other code examples of getting the required tasks (etc) information that could help springboard us into the development? (I.e. load all task assigned to a user, or that could be completed by a user or a user’s group, etc.)

Also, if we do go down this development road, I am happy to provide back source if anyone is interested (though note that I not an experienced portlet developer, only created a few smallish and stand alone ones thus far, and am obviously not an experienced Camunda developer :slightly_smiling: ).


Hi Colin.

There is no generic portlet available – also I think it will be hard to build – as portals and requirements differ very much.

We identified 3 basic possibilities (see picture below):

- Write one Portlet doing everything and presenting just generic forms (a bit like Camunda Tasklist with Generated Forms)

- Write one Portlet doing everything but load HTML snippets to be shown as tasl forms (like Camunda Tasklist with Embedded Forms)

- Write one Tasklist Portlet and separate portlets for task forms. This is by far the most flexible in terms of task forms, but involves inter-portlet-communication (which can get a pain)

In Liferay I would try to leverage Java API of Camunda as it is easier to do. But this depends on your overall architecture. Maybe you run Camunda and Liferay on the same Container (e.g. Jboss) – then this is easy to do. If you run them on different servers you still might want to run a Camunda Instance on the Liferay container to build the tasklist, but it has the same restrictions as our “Standalone Webapp” – I copy an extract from our Consulting Best Practices:

Standalone Webapp: You can deploy the "Camunda Standalone Webapp", which is a WAR running a small Process Engine inside of it. It is configured to look into the same database as your Remote Engine - and therefor can query and complete tasks. In this scenario you need database access from the "Camunda Standalone Webapp", but you’ll have one important restriction: When you complete a task, the process instance moves on. If it hits Delegation Code you are on the wrong engine which does not know your Java classes, hence you will get Exceptions. So you have to make use of Safe Points in your process model, then the execution of the process instance is done by the Remote Engine having all necessary classes deployed. This implies that process execution will be asynchronous.

Hope that helps.



PS: We do also offer consulting services to support you in your endeavors ;-)

1 Like

Hi Berndt,

Sorry, I missed this reply message (otherwise I would have replied earlier).

Thanks for that info…

At this stage I seem to be heading a bit down Variant 3 with maybe some Varient 2 :slightly_smiling:. I am planning to have a portlet that in edit mode will allow the (admin) user to enter a process id/key and then allow the user to “decorate” the portlet/Camunda fields.

The use case is to allow the (relatively) easy creation of the start forms with fields coming from Camunda but with added labels, hints, formatting, etc., being added by the admin user to help out the normal user.

I can see how this could work for the start form (each start form would be its own portlet), but not sure how (or where) to put such configuration for the following task forms. Possibly that is where the variation 2 might come in, or possibly I might fall back to the normal Camunda tasklist UI.

Your discussions on whether to use the Java API or the Rest API are interesting… I did not think I could use the Java API if the Liferay instance was running on another server… I shall look into this.

My Java Rest knowledge is a little limited, I have managed to get data back from the rest API and plant it into some of the Camunda Java objects, like so:

public static void printoutSingleDef3ShorterVer() {
	Client client = ClientBuilder.newBuilder().build();
    for (Class<?> clazz : CamundaRestResources.getResourceClasses()) {

    for (Class<?> clazz : CamundaRestResources.getConfigurationClasses()) {
    WebTarget target ="http://localhost:8090/engine-rest/process-definition/key/myTestProcess");
    ProcessDefinitionDto value = target.request().get().readEntity(ProcessDefinitionDto.class);

But ideally, if continuing down the Rest track, it would be nice to be able to call the rest api java classes more directly than what I have done in this example. As mentioned, My Rest knowledge is pretty limited, but I am keen to get something like:

WebTarget target ="http://localhost:8090/engine-rest");
/// ...some code to bind the target to the rest service...
ProcessDefinitionRestService service = ???

ProcessDefinitionResource resource = service.getProcessDefinitionByKey(myTestProcess);
// etc

Not sure if anyone can provide any more pointers in this regard.

Also a note about your consultancy services, this might be a possibility… some bigger boost to get us going in the right direction might be quite useful… note sure quite how to define that yet however :slightly_smiling:.