5 Replies Latest reply on Apr 30, 2009 1:14 AM by Ronald van Kuijk

    Design Patterns

    Ron Wallis Newbie

      Hi I new to the forum but have been using jBPM for a bit now (and loving it). I have a couple "design pattern" questions to ask.

      1) Should jBPM be used as a "fancy" server side batch processor/scheduler where the token recurses from one processing node to a decision node and then, based on the decision, back to the processing node using a timer thats set at some interval like 1 minute? Will this cause stack overflow problems eventually? Will this cause the log file to get ridiculously large?

      2) What is the practical limit of child token hierarchy levels? In other works if a fork is used to send a token back to the node it came from and parallel another token to a different node (resend algorithm), what limit should be put on the resend (or should this algorithm simply not be used), before the child tokens get to be too many and stack over flow occurs?

        • 1. Re: Design Patterns
          Ronald van Kuijk Master

          First of all, thanks for taking the time to post in the correct forum. In return I should take the time to at least try to answer your question.

          1) If there is a real persisted wait-state in this loop, you should not get a stackoverflow.

          2) If I understand you correctly, you want to have e.g. a node in one 'leg' of a fork go back to the fork node but as a new loop? That is not advised (though it might work, you could give it a try in a unittest). Using recusive subprocesses can be done.

          From what I read, both questions are related. Maybe it is better to give your functional requirements so we can discuss those and try to find a solution that fits.

          • 2. Re: Design Patterns
            Ron Wallis Newbie

            1) there is a real persisted wait state (and its set from one minute to 19 days depending on the action taken by the user) but we have been getting stack overflow errors (after running 24/7 for about 2 weeks) and then timers stop working (we have to restart the application server) and this is considered the culprit. Given this, one of our developers doesn't want to use jBPM for batch processing that would require escalation (via a timer) every minute. I however would like to use jBPM because then we could leverage jBPM to create fail/retry logic with nodes and the jBPM console for visibility into the batch processing. (and yes there probably are alternatives to using the same token over in a loop but again thats why this was titled design patterns).

            2) In the second part, in its simplest, its a task node to a fork with one transition from the fork going back to the task node and a second transition from the fork going to a different task node. When done manually from the first task node (user signals the transition rather then some external event or a timer) its an easy way to allow for a "Resend" A simple example would be "Supervisory Approval" where tokens comes into a "Processor" task node wHere they transition the token to "Supervisor Approval" but still want the token to remain in their task node in parallel, having the "send for approval" transition go to a fork solves this easily, the token goes back to the "Processor" task node and then also goes to the "Superviosr Approval" task node (with a join at the end of all of this of course). The processor continues to have it as an active task and so does the supervisor, then if the processor has an additional task that needs to be done by the supervisor (but again wants to continue to have the task as well) they simply transition the token to the supervisor task node again. In testing this all works perfectly, and all of the child tokens complete out of the join properly but it does seem that there is a limit to the number of inherited children (like maybe 1000) so if the transitions are manual no problem but if automated with timer then its a problem. The question was asked because there is concern that some "idiot" might want to click the button 1000 times an therefore cause stack overflow to occur, we can put a check in to limit this to something reasonable like 10 times but maybe we shouldn't do this at all...

            P.S. sorry about posting initially to the wrong forum.

            • 3. Re: Design Patterns
              Ronald van Kuijk Master

              1) Yes the logfile will get large

              2) on second thought, you never reach the correct join node (every node between a fork/join should be fully nested) so as I also stated, use e.g. a subprocess for this.

              I thank you for your description, but it is a description of a possible implementation, *not* your functional requirements. Since some things you describe do not work in jBPM(at least I think they don't in they way you describe it) it is hard to understand what you want.

              • 4. Re: Design Patterns
                Ron Wallis Newbie

                1) The log file could be a problem... thanks
                2) the token does reach the join and continues on through (we though the same thing but upon testing and looking at what the database did, it worked)

                3) there are two functional requirements:

                a) I'll skip the batch processing functional requirements because at this point they are vague. (Basically processing as files are uploaded into a directory or when a record in an external database is updated, etc. and probably the challenge here is more in deciding to write a custom action or a custom node... or because logging could get out of control don't do it in jBPM.

                b) User has a task but supervisor should also get a task every day task sits in processors list of tasks. All tasks as related to the initial task from a reporting standpoint.

                • 5. Re: Design Patterns
                  Ronald van Kuijk Master

                  3a) e.g. use an esb with a file/db poller and have that action signal a process.

                  3b) Look at my blog, there is an example of creating runtime tasks that could be leveraged in this case in combination with a timer