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.

ejb service task 'interface'

ronald_van_kuij

As discussed with Tom in the userforum, we'll be implementing the ejb and jms service tasks. There are many ways the calls can take place. I'd like to propose some things here for the initial implementation of the ejb service task. A similar post will come for the jms service task

First of all there is the local or remote option. Initially I think focussing on local is good enough, but if someone disagrees, feel free to comment.

Secondly, there is the choice to just call an existing ejb with a predefined interface or to have it implement an activiti specific interface kind of like the java delegate. I prefere to initially focus on existing interfaces where context variables are passed on in the method call, but again, if someone disagrees…. So a method name is needed, a list of parameters (order is important)

Thirdly there is the return value. Should it be taken into account? It probably needs to be if it is about existing interfaces where you cannot add variables to the execution (if possible at all).

But most importantly, is it a new service task or is it an addition to the java service task. Personally I'm in favour of the latter. The difference is not that big and it is probably even possible to use juel to resolve ejb's (high om my todo list, cdi?) and call the corresponding methods like in Seam. Using a 'type' like for the mail task is not what I'd do for ejb calls (I would for jms though)

So to summarize and propose element/attribute names
- only local calls (attribute, activiti:jndi-name)
- define a method name (attribute, activiti:method)
- define parameters (extension element, activiti:arg, order is important, should be like the method signature and is comparable to the activiti:field)
- define return value (extension element, optional: activiti:return)

Thoughts?

Find more posts tagged with

Comments

tombaeyens

First of all there is the local or remote option. Initially I think focussing on local is good enough, but if someone disagrees, feel free to comment.

starting with local is OK. later you could add remote if there is demand for it.

Secondly, there is the choice to just call an existing ejb with a predefined interface or to have it implement an activiti specific interface kind of like the java delegate. I prefere to initially focus on existing interfaces where context variables are passed on in the method call, but again, if someone disagrees…. So a method name is needed, a list of parameters (order is important)

it's important that you stick to the existing ejb interfaces. users should not implement JavaDelegate.
Apart from method name and parameters, I think you also will need the local ejb name (JNDI name?) to look up the local home interface.

Thirdly there is the return value. Should it be taken into account? It probably needs to be if it is about existing interfaces where you cannot add variables to the execution (if possible at all).

It should be possible to pass in the execution as a parameter in a method invocation (just like any other parameter)
Apart from that, the return value should optionally be captured and stored in a variable.

In terms of passing the parameters, compare it with method expressions passing in parameters. There's already a lot that you can do with that. And it is already possible somehow to invoke an ejb through a method expression. (maybe Joram can give pointers) Can you first evaluate when users should use method expressions with parameters and when they should be using the ejb activity? Once that is cleared out, then it also gives you better guidance for which features to develop first.

But most importantly, is it a new service task or is it an addition to the java service task. Personally I'm in favour of the latter … Using a 'type' like for the mail task is not what I'd do for ejb calls (I would for jms though)

Tijs, is there a preferred way from the designer point of view? Maybe in context of the pluggability?

… and it is probably even possible to use juel to resolve ejb's (high om my todo list, cdi?) and call the corresponding methods like in Seam.

first I explain that idea in detail and now you pretend that you had already thought about it before… tsssss

So to summarize and propose element/attribute names
- only local calls (attribute, activiti:jndi-name)
- define a method name (attribute, activiti:method)
- define parameters (extension element, activiti:arg, order is important, should be like the method signature and is comparable to the activiti:field)
- define return value (extension element, optional: activiti:return)
Thoughts?

looks perfect to get started, but first evaluate how and where this is different from method expressions.

it might also be early days for creating unit tests for this. i have high on my agenda to run the test suite in container on hudson (this release?). but i'm not there yet.

jbarrez

Regarding the 'pointer' refers to. A few months ago, I tried to wrap an EJB in a Spring bean anc call it through a method expression. That just worked as a charm, but you needed Spring obviously.

ronald_van_kuij

it's important that you stick to the existing ejb interfaces. users should not implement JavaDelegate.

Ok, good to get my view confirmed. I could not find a good reason to go this way.

In terms of passing the parameters, compare it with method expressions passing in parameters. There's already a lot that you can do with that. And it is already possible somehow to invoke an ejb through a method expression. (maybe Joram can give pointers) Can you first evaluate when users should use method expressions with parameters and when they should be using the ejb activity? Once that is cleared out, then it also gives you better guidance for which features to develop first.

Personally I prefer the expression way. Most likely this can only be used if the ejb has a mapped name or something. Will try this out comming days

But most importantly, is it a new service task or is it an addition to the java service task. Personally I'm in favour of the latter … Using a 'type' like for the mail task is not what I'd do for ejb calls (I would for jms though)
Tijs, is there a preferred way from the designer point of view? Maybe in context of the pluggability?

If expressions already work, I'd certainly try to use the same task and not create an ejb-service task

… and it is probably even possible to use juel to resolve ejb's (high om my todo list, cdi?) and call the corresponding methods like in Seam.
first I explain that idea in detail and now you pretend that you had already thought about it before… tsssss

Sorry…. 🙂

looks perfect to get started, but first evaluate how and where this is different from method expressions.

it might also be early days for creating unit tests for this. i have high on my agenda to run the test suite in container on hudson (this release?). but i'm not there yet.

I've used arquilian from JBoss for this recently somewhere. Works great… it supports more than ejb-unit, is a bit slower when the container needs to be started, but it's only 30 seconds

ronald_van_kuij

Regarding the 'pointer' refers to. A few months ago, I tried to wrap an EJB in a Spring bean anc call it through a method expression. That just worked as a charm, but you needed Spring obviously.

Ok, but that would require coding? Or can the spring bean be generic? Isn't a resolver for juel another option?

jbarrez

Or can the spring bean be generic

Good question, didnt try that yet. I'll give it a try tonight.

Isn't a resolver for juel another option?

If you want method expression without a spring bean, probably yes.

ronald_van_kuij

Or can the spring bean be generic

Good question, didnt try that yet. I'll give it a try tonight.

Isn't a resolver for juel another option?

If you want method expression without a spring bean, probably yes.

I'll focus on this one then…

bernd_ruecker

I would like to see the resolving of the EJB references pluggable, so JNDI is the default, but Service Registry could be maybe plugged in later.

I don't see a big difference between local and remote (except for the JNDI name and call by reference semantic), so I would target both. Actually I think remote is the bigger use case.

ronald_van_kuij

For remote you also need to provide context information like url, usename, password. But no worries, it will be taken into account for 5.3 the rest could maybe make it in 5.2

pluggability for resolving would be an option, but I don't think not implementing it now makes it more difficult later

ronald_van_kuij

sorry that should both be a minor version more… jira freeze was aleady passed for 5.2

tombaeyens

Here's a pointer that I want to share: In order to map the ejb-logical names to the expressions name resolution, you should probably update this section in ExpressionManager

 protected ELResolver createElResolver(VariableScope variableScope) {<br>&nbsp;&nbsp;&nbsp; CompositeELResolver elResolver = new CompositeELResolver();<br>&nbsp;&nbsp;&nbsp; elResolver.add(new VariableScopeElResolver(variableScope));<br>&nbsp;&nbsp;&nbsp; elResolver.add(new ArrayELResolver());<br>&nbsp;&nbsp;&nbsp; elResolver.add(new ListELResolver());<br>&nbsp;&nbsp;&nbsp; elResolver.add(new MapELResolver());<br>&nbsp;&nbsp;&nbsp; elResolver.add(new DynamicBeanPropertyELResolver(ItemInstance.class, "getFieldValue", "setFieldValue")); //TODO: needs verification<br>&nbsp;&nbsp;&nbsp; elResolver.add(new BeanELResolver());<br>&nbsp;&nbsp;&nbsp; return elResolver;<br>&nbsp; }<br>

At this point, this list of ELResolvers is not yet configurable (but the expression manager is). I can help do that if necessary. But first go ahead and play with it so that we know exact what kind of configurability we need.

ronald_van_kuij

Yep, already found that. Initial version already working… testing is more difficult than creating the code. Have added the EJBResolver at the end.

ronald_van_kuij

Ok, the real integration is more difficult than I thought compared to the code needed to resolve and call an ejb. The juel stuff is focussed on valueExpressions whereas in this case the method expression is a better fit. But how and when juel decides this is still not clear to me. So this might still take a few days to crystalize, but it will work…

Ronald

jbarrez

Ronald, what's the isssue? Frederik is a Juel-expert by now, so he will be able to help you further if needed.

ronald_van_kuij

Sorry, already found it…. was VERY easy (once you know it). The getValue() in a new resolver is also used to resolve bean/variable/map/… and thus the ejb to. I missed that part (still had the jBPM way in mind).

So it works. with only

<br>&nbsp; private final boolean isResolvable(Object base, Object property) {<br>&nbsp;&nbsp;&nbsp; return base == null && property != null && property instanceof String;<br>&nbsp; }<br><br>&nbsp; @Override<br>&nbsp; public Object getValue(ELContext context, Object base, Object property) {<br>&nbsp;&nbsp;&nbsp; Object o = null;<br>&nbsp;&nbsp;&nbsp; if (isResolvable(base, property)) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // Properties currently read from jndi.properties<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; o = InitialContext.doLookup((String) property + "/remote");<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } catch (NamingException e) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // TODO logging&hellip;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; e.printStackTrace();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; context.setPropertyResolved(true);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return o;<br><br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; return null;<br>&nbsp; }

for the resolving. The execution itself is done by the BeanELResolver…. since that is about invoking methods etc…

Some tuning needed for the 'remote' part in names or custom names, but that will be no problem. Beans with complex jndi names will probably be difficult, but there is where the 'full' configuration comes in.

ronald_van_kuij

Ok, calling ejbs from an expression works. Currently with the following limitations:
- ejb name should be one that can be used as a 'property', so no /,._ etc
- first tries <name>, then <name>/local
- No access to beans that require authentication

For remote beans some way to provide the initial context should be used
and maybe a way to provide authentication, or accept these limitations and only use this for local beans.

Still, a way to provide a more complex name for local beans would be nice.

jbarrez

Ronald, I found my Spring/EJB example, and made a blogpost of it:

http://www.jorambarrez.be/blog/2011/01/13/tutorial-call-an-ejb-in-a-bpmn-2-0-process-using-activiti-and-spring/

Probably the approach can be made generically, by looking into the classes that wrap the actual EJB.

ronald_van_kuij

Yep, read it, commented and send you something (also attached to http://jira.codehaus.org/browse/ACT-537)

tombaeyens

Ronald, I assume that the EJBResolver had dependencies on some libraries. Right?
If so, did you make the EJB resolver optionally configurable?

ronald_van_kuij

No, no dependencies…. All it does is a simple jndi lookup, returns an Object and the BeanResolver can execute methods on the bean. That was really all that was needed for the simple version.

The only thing still needed is to swallow the jndi lookup exception if nothing is configured since the EJBElResolver will always go of if nothing matches. We might try to do something creativly here if the instantiation of the InitialContext fails and we can detect that we do not have context at all.

ronald_van_kuij

But it would indeed be possible to e.g. make it configurable in the config… would solve the creative looking at the jndi lookup. Will look into that.

ftr

Hey guys,

Access to local EJBs from service tasks is exactly what I need. Do you know when this feature will be included in an official release? I've seen the patch in JIRA, but I'd prefer to use an official release.