1 2 Previous Next 20 Replies Latest reply on Mar 10, 2008 5:36 AM by koen.aers

    Less coding by custom nodes/jrules/etc...

    trouby

      Hey,

      I'm finding myself writing a lot of processes nodes that make a usage of the same java code but with very simple modifications,

      Then, I think writing custom nodes that will receive information(probably as parameters of the custom nodes) when drawing the node will solve the code re-write,

      Also, I assume Jboss rules can be used with JBPM to simplify rules instead of using java code as well,


      My mission is that I would really love to see how non-developers can use our platform to define processes without the need to write Java code at the backend.


      So here are my questions:
      1) Is it possible to create custom Nodes and set some parameters when drawing the node in the process? In the doc of JBPM it is written that it's easy but I couldn't find any samples, etc...
      2) After browsing the forum a little bit, I can see that extending the designer is currently not an easy task, is it going to be changed? will it be easier in the future? what's the plans here?
      3) Are there any other usages/samples of using JBPM with jboss rules except the small example in the wiki?


      For the start, I'll be glad to write the custom nodes, and use them in the processdefinition xml file manually, later on, when it'll be possible, I'll define these custom nodes on the designer as well,


      Many thanks guys,

      Asaf.

        • 1. Re: Less coding by custom nodes/jrules/etc...

           

          "trouby" wrote:
          I'm finding myself writing a lot of processes nodes that make a usage of the same java code but with very simple modifications,

          Then why not re-use the same handler code?

          Make sure the handler has a field/setter and then when you use the handler, pass in a parameter to modify the behaviour. Doesn't even need a custom node implementation.

          • 2. Re: Less coding by custom nodes/jrules/etc...
            trouby

            Hey,
            Thanks for answering,

            Few reasons:

            1) In the future, it'll be easier to customize things visually through nodes, selecting handles is not nice as dragging nodes,
            2) Customizing parameters of nodes can be done visually, handlers receive info as method parameters, which is not nice as visual form fields (btw, I don't use handlers at all, I use expressions and invoke Seam components, but it's about the same implementation)
            3) I have too much information to pass, it'll be easier to pass it via a new structure of the node in the processdefinition.xml

            So, for the start, is it possible to customize nodes? if so, is it documented? somehow? somewhere? samples? :)



            Thanks,

            Asaf.

            • 3. Re: Less coding by custom nodes/jrules/etc...

               

              "trouby" wrote:
              So, for the start, is it possible to customize nodes? if so, is it documented? somehow? somewhere? samples? :)

              If you haven't yet, then download the jBPM source code (http://docs.jboss.com/jbpm/v3/userguide/gettingstarted.html#cvsaccess) and check out the unit test code and samples - there may well be something to guide you there.

              The userguide has also got some info: http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#customnodebehaviour

              Hope these help.

              • 4. Re: Less coding by custom nodes/jrules/etc...
                trouby

                Hey,

                I already read the whole doc from top to bottom :)


                I'll try to download the source code, hopefully there's a full sample (custom node/process that make a usage of the custom node, etc...)

                I thought that this is something very common,


                Thanks,


                Asaf.

                • 5. Re: Less coding by custom nodes/jrules/etc...
                  kukeltje

                  Customized node via delegation classes yes, custom nodes that have their own 'look and feel' in the GPD no.. Although the esb node is a kind of intermediate.

                  No this is not common. Since jBPM can be functionally extended with actions on nodes in a way that custom nodes are not often needed.

                  • 6. Re: Less coding by custom nodes/jrules/etc...
                    trouby

                    Hey,

                    Can't I just have my own node type? maybe extended from the generic node available in JBPM

                    like there's / <task-node> I would like to have my own node tag, fully described differently, with different tags and parameters?



                    Thanks,

                    Asaf.

                    • 7. Re: Less coding by custom nodes/jrules/etc...

                       

                      "trouby" wrote:
                      Hey,

                      Can't I just have my own node type? maybe extended from the generic node available in JBPM

                      like there's <node> / <task-node> I would like to have my own node tag, fully described differently, with different tags and parameters?

                      Then you'll also have to customise jBPM so that the XML parses correctly, add the necessary code to the GDP so the design can be rendered etc.

                      Sure, it can be done, but sounds to me like a whole lot of effort for little reward.

                      • 8. Re: Less coding by custom nodes/jrules/etc...
                        trouby

                        Hey,

                        Well, the designer is not so easily extend able, I better leave it for now,


                        What about extending the default node, but having more tags specified in its body? aint there an example for that? I hope there is, I also hope that the engine delegates the XML tags to the node execution itself so I can read them, if this is possible, then great.

                        Anyone?


                        Thanks,
                        Asaf.

                        • 9. Re: Less coding by custom nodes/jrules/etc...

                           

                          "trouby" wrote:
                          Well, the designer is not so easily extend able, I better leave it for now,

                          Wise decision...

                          "trouby" wrote:
                          What about extending the default node, but having more tags specified in its body?

                          You could, but that'll still mean changing the core jBPM source to have them parsed.

                          "trouby" wrote:
                          I also hope that the engine delegates the XML tags to the node execution itself so I can read them, if this is possible, then great.

                          The tags are delegated to the node class, but at the time the definition is read from the XML source - so not at execution time. (At least, I'm pretty sure that's how it is.)

                          You could add configuration in the jbpm.cfg.xml if you want to defer evaluation till runtime - check out http://docs.jboss.com/jbpm/v3/userguide/mail.html#mailserverconfiguration and see how that's used to configure email nodes.

                          e.g.
                          <jbpm-configuration>
                           ...
                           <string name='resource.mail.properties' value='jbpm.mail.properties' />
                          </jbpm-configuration>

                          [/url]

                          • 10. Re: Less coding by custom nodes/jrules/etc...
                            kukeltje

                             

                            "trouby" wrote:
                            What about extending the default node, but having more tags specified in its body?

                            You could, but that'll still mean changing the core jBPM source to have them parsed.


                            No not needed. just add an action to the node to give it the behaviour you want. No need to change any core jbpm source.

                            The tags are delegated to the node class, but at the time the definition is read from the XML source - so not at execution time. (At least, I'm pretty sure that's how it is.)


                            If you put xml tags in as params, they'll be passed, runtime, to your node implementation in the form of an XML Document object. regardless of which tags you put in. See http://docs.jboss.com/jbpm/v3/userguide/jpdl.html#configurationofdelegations

                            How you parse the content of what is in there is completely up to the developer

                            • 11. Re: Less coding by custom nodes/jrules/etc...

                               

                              "kukeltje" wrote:
                              See http://docs.jboss.com/jbpm/v3/userguide/jpdl.html#configurationofdelegations

                              How you parse the content of what is in there is completely up to the developer

                              I had another look at that and came up with the following:

                              <process-definition xmlns="" name="TestProcess">
                              
                               <start-state name="startstate">
                              
                               <transition to="node1" name="ok">
                               <action name="Test1" class="TestHandler" config-type="constructor">
                               <blob>This is some constructor config data</blob>
                               </action>
                               <action name="Test2" class="TestHandler" config-type="field">
                               <blob>This is some field config data</blob>
                               </action>
                               <action name="Test3" class="TestHandler" config-type="bean">
                               <blob>This is some bean config data</blob>
                               </action>
                               </transition>
                               </start-state>
                              
                               <node name="node1">
                               <transition to="end"></transition>
                               </node>
                               <end-state name="end"></end-state>
                              </process-definition>


                              and

                              import org.apache.commons.logging.Log;
                              import org.apache.commons.logging.LogFactory;
                              import org.jbpm.graph.def.ActionHandler;
                              import org.jbpm.graph.exe.ExecutionContext;
                              
                              public class TestHandler implements ActionHandler
                              {
                               private static Log log = LogFactory.getLog(TestHandler.class);
                              
                               public String blob;
                              
                               public TestHandler()
                               {
                               log.debug("Default constructor");
                               blob = "default";
                               }
                              
                               public TestHandler(String xml)
                               {
                               this();
                              
                               log.debug("Config constructor");
                              
                               configure(xml);
                               }
                              
                               public void configure(String xml)
                               {
                               log.debug("Parse: " + xml.trim());
                               }
                              
                               public void setBlob(String blob)
                               {
                               log.debug("Setter");
                               this.blob = blob;
                               }
                              
                               public void execute(ExecutionContext executionContext) throws Exception
                               {
                               log.debug("Execute: " + blob);
                               }
                              
                              }
                              


                              Hope that helps :)

                              • 12. Re: Less coding by custom nodes/jrules/etc...
                                kukeltje

                                correct and String blob can also be a List, Map, Document, whatever.... see the unittests for all kinds of examples

                                • 13. Re: Less coding by custom nodes/jrules/etc...
                                  trouby

                                  Cool,

                                  btw, the reason I was trying to do everything through different type of nodes is the designer,

                                  At the end, I would like to see a designer with different type of nodes that are draggable, and have different behavior,

                                  With the suggested way here, in the future, the designer will still only have 1 generic type node (as available now) but with different actions, which is not nice as having different guitable nodes :-)


                                  Cool, I'll use actions for now as new nodes seems to be too complicated

                                  (although I'm pretty sure in the doc it is written that it is possible to add new nodes easily)


                                  Thanks for the answers guys, really.

                                  Thanks,

                                  Asaf.

                                  • 14. Re: Less coding by custom nodes/jrules/etc...

                                     

                                    "trouby" wrote:
                                    (although I'm pretty sure in the doc it is written that it is possible to add new nodes easily)

                                    This is where you learn that 'easy' is a relative term - no doubt whoever wrote that does consider it 'easy' - doesn't mean it actually is easy. LOL.

                                    1 2 Previous Next