12 Replies Latest reply on Dec 1, 2005 7:01 PM by Ronald van Kuijk

    Jpdl XSD Schema

    Eduardo Jimenez Newbie

      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.

        • 1. Re: Jpdl XSD Schema
          Ronald van Kuijk Master

          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?

          • 2. Re: Jpdl XSD Schema
            Tom Baeyens Master

            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.

            • 3. Re: Jpdl XSD Schema
              Tom Baeyens Master

              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.

              • 4. Re: Jpdl XSD Schema
                Ronald van Kuijk Master

                 

                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


                • 5. Re: Jpdl XSD Schema
                  Tom Baeyens Master

                  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.

                  • 6. Re: Jpdl XSD Schema
                    Ronald van Kuijk Master

                    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?

                    • 7. Re: Jpdl XSD Schema
                      Eduardo Jimenez Newbie

                      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.

                      • 8. Re: Jpdl XSD Schema
                        Ronald van Kuijk Master

                        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

                        • 9. Re: Jpdl XSD Schema
                          Eduardo Jimenez Newbie

                          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

                          • 10. Re: Jpdl XSD Schema
                            Ronald van Kuijk Master

                            Ed,

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

                            • 11. Re: Jpdl XSD Schema
                              Eduardo Jimenez Newbie

                              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

                              • 12. Re: Jpdl XSD Schema
                                Ronald van Kuijk Master

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