nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Activiti deployment? How do you deploy Activiti at your org?

rickhigh

I am trying to get some ideas on how people deploy Activiti. Do you use it embedded? Did you just extend the REST-API war project? Do you actually deploy jar files to the REST-API war project? etc.

We have a project that is going to manage a series of batch jobs. Described here under problem domain. The first phase of the project will require no human interaction (HI), but future phases will.

I don't want to include HI, but I don't want to preclude it either.

It seems, in order to use the tools for Activiti with all of its tooling, tracking, auditing and process viewing, we need to deploy our jars under the activiti-rest webapp. Essentially the tools (modeler, probe, explorer, etc.) use the REST API for Activiti (I think).

I think we want to reduce this type of deployment as much as possible, i.e., we don't want to deploy just jar files that have tasks.

I assert: If we want custom tasks and want to use the Activiti tooling (likely as per last meeting at work) then we will have to deploy Java classes (jar files) into that webapp or create a webapp that encompasses our tasks and the REST API. I don't like this approach. I don't think we would be able to get this past SCM group.

The other option is to get a process id for the workflow send this around and have the clients of the workflow mark the current task as done (which will advance it to the next task or branch decision). This approach relies heavily on the API and in my opinion violates separating areas of concern.
Our original idea (Ian and I's) was to use a message bus (Spring Integration) to mark the task done and then each task sends out a message where one or more batch processes (living in another JVM) will handle that step and send a done message when they are done.
The other possibility is to run embedded and not use the tools (no chance of HI in the future and we loose a lot of the tracking ability of the workflow).

More complete posting with a list of possible options

Find more posts tagged with

Comments

ronald_van_kuij

Rick,

We develop our own web ui for HI and some monitoring things (activiti probe) since it has to integrate with things we already have. Activiti has a fairly clean rest-api for this, which we will not use, we use the java api since our webapp does not need rest, it is, at least serverside, java.

But the flexibility that activiti provides is enormous. You could deploy probe on a different machine just to do monitoring but point it to the same database as the engine.

Regarding the use of tooling and deploying jars etc, it also has more options than you think. What will be in 5.3 is the option to call ejbs, which in my opinion are with 3.0 and better, 3.1 certainly not evil any more. At that time you can call an ejb by just using an expression like #{ejbname.method(variable1, variable2)} or whatever combination of parameters. These parameters can just be the names of the process variables. The only limitation is the name of the ejb, but if they are under your control that is no problem. More extended local calls and remote calls will also be possible but that would require a little more attributes on a java task.

In this situation, you can deploy services in jars independently of engine and certainly independent of the webapp and you do not need any custom task. I don't think SCM will have a promblem with this, they don't have at our company.

When I read your blog, all the options kind of felt fabricated and the one I describe above in my (personal) opinion does not.

And if you look at it a little more closely, it is a decent kind of 'SOA'. We came to the conclusion (I personally already did 3-4 years ago) that to do 'SOA' you do not need an 'ESB'.

ronald_van_kuij

Rick,

I forgot to mention that since the ejb's are called via reflection, you do not even need to deploy interfaces in the engine. Nor do your ejbs have to implement a special interface. Any public method can be called and you can have multiple methods in one bean.

rickhigh

EJBs are out of the picture for us. Spring is not. (This is not an opinion or a critisim but just what our current environment is like.)

We have our own services which are housed in a home grown container (It is Java, but not JEE). It is accessible via JSON/RPC calls.
We do use Spring.

So with the EJBs, don't the client jar files have to be assessable from the war file.

It seems like you still need some custom libraries where the workflow lives to house the client stubs for the EJBs.

Good information about still being able to use the tools even if you are using an embedded version of the workflow.

You have given me a lot to think about.

Also we have long running processes, 2 minutes to several hours. We are kicking of batch jobs not really making just service calls so not sure EJB or Spring Service (or even our Services) are a good fit per se. Unless of course they just kick off one of the batches.

I am not sure I 100% understand your response so… not sure I can respond well.

thomas1

Hi Ronald,

Rick,

I forgot to mention that since the ejb's are called via reflection, you do not even need to deploy interfaces in the engine. Nor do your ejbs have to implement a special interface. Any public method can be called and you can have multiple methods in one bean.

I did a proof of concept with Activiti using Spring but I'd prefer to drop Spring and use EJB 3.0.

Do you have something around to test yet? I saw your patch for calling EJBs. Should I apply the patch to 5.2 or is there something newer/better around yet?

Thanks,
Thomas

ronald_van_kuij

So with the EJBs, don't the client jar files have to be assessable from the war file.

It seems like you still need some custom libraries where the workflow lives to house the client stubs for the EJBs.

No, I thought that to initially, but the only reason you need the interfaces is if you want to be able to cast to a specific type and be able to call methods directly on them. What happens in this case is a jndi lookup that returns an Object (so no casting to anything) and since you already specified in the expression what method you want to call and it can deduce the parameter types from the variables, it uses reflection to find the correct method (one with the correct signature (just not taking te return value into account). This is not something we invented, but part of the basic EL resolving functionality initially just for beans, it works in this case to.

For the rest I think you understood everything I posted, but if you have questions, do not hasitate to ask.

ronald_van_kuij

Hi Ronald,
Do you have something around to test yet? I saw your patch for calling EJBs. Should I apply the patch to 5.2 or is there something newer/better around yet?

For local EJB's with names you have under control this is currently it. There will not change that much either on short notice, only the 'full' ejb config (initial context etc) will become available.

I did not test the patch against 5.2, so your milage may very, but I think it will be fine

tvetter

hi ronald,

the EJB integration is a great feature. will it be included in release 5.3?