Jpdl XSD Schema

[ejimenez]

I realize this may not really matter much but, it seems kind of silly that the jpdl xsd schema verifies the type attribute of the event element when the manual clearly states that custom event types are allowed by simply using any identifier string in the type attribute.

Clearly everyone must agree that the XSD should validate any valid JPDL document, and ... is clearly legal.

[kukeltje]

afaik, custom event types are to be used on custom nodes. The generic node type should indeed support more and the xsd should indeed validate those.

but it is indeed possible to define other events on specific nodes. imo that should not be supported. The danger is that you start programming to much in the nodes and 'abuse' it in a kind of async manner. So my proposal would be to make the xsd validate just custom events on the generic node type and not the others.

Comments?

[tom.baeyens]

you can associate actions with any event on any node and fire these events at runtime.

the jbpm implementation (nodes+engine) will however fire only the documented event types.

so if you put an action on a custom event type on any node, it will only be executed if you explicitely fire that event on that node (e.g. in an action, in a node implementation or from your client code).

regards, tom.

[tom.baeyens]

so indeed, the xsd should be updated in this respect.

the only problem is that the xml editor will not give the predefined event types with code completion...

but you're right, there's no other way. we need to make sure that any valid jpdl xml passes through validation. so i'll try to update that.

regards, tom.

[kukeltje]

you can associate actions with any event on any node and fire these events at runtime.

hmm... The option for custom events on the generic 'node' type is good, but custom events on specific (jBPM defined) node types is imo less (not?) needed? I'd like the functionality of code completion much better than the need for custom events.

If we just allow it on 'node' it is easy to define in the xsd, while retaining codecompletion on the other nodes

[tom.baeyens]

i tried a couple of ways, but not satisfactory cause i'm not an xsd expert.

what i would like is that you get the known event types with code completion but that you still can enter any piece of text if you want to.

any idea on how to do this in xsd ?

regards, tom.

[kukeltje]

Yep, I think I do (i hope). if there is a jira issue, assign it to me and put it for 3.1beta.

If It is not possible, what should we do? go for code completion on nown node types and no code completion for the custom node types?

[ejimenez]

In the meantime, we simply switched from using events to simple transitions. We were using events to model points where we have to wait for external systems (which is pretty much the definition of a state in your manual), kind of like emulating an event choice node....depending on which event we received from the external system, we took different transitions/actions.

It seems to make sense to me to allow it there as well as in a custom node.

[kukeltje]

Sound's like you used events where you mean you wanted to 'signal' the state to advance. You could also set a process-variable (call it 'event' ;-) ) and just signal the node and have it advance based on the value of the process variable, maybe even scripted on the transitions . Then you have the same functionality.

Ronald

[ejimenez]

Well, yes that would work except it ties up services (that are called before expecting an "event") to jBPM, which is exactly what we want to avoid.

I'll create a separate posting for a couple more issues we've found with the XSD schema.

Thanks,

Ed

[kukeltje]

Ed,

I do not get what you mean by 'ties up services....' . I't's probably me, but could you explain a little more?

[ejimenez]

Again, our processes are atypical usage of jbpm but we have certain operations that have to get done in a process, but that take a lot of time to complete (could be 10 seconds up to 60 days). Within our workflow, we send such actions to a specific (async) service, then just expect an event back form it with the result of the action......kind of what you guys have done with the async="true" but more specialized for our domain.

Anyhow, we don't want the asynchronous service to know anything about jBPM, signal or anything....we want workflow decisions to happen at the workflow engine. Since we want to keep jbpm mods to a minimum, we have wrapped jbpm in our own apis that allow us to do just that. The services just raise events to the wrapper to notify it of things that have happened. The wrapper uses process information/state to determine whether the process needs signaling or not.

Hope that clears it up

[kukeltje]

tnx, I agree. Wrapping is a good thing in this case. I just did not understand this was what you meant.