Series: Idiotic Mistakes to avoid with Savvion - Part I
I have tried to compile a list of some idiotic things you could end up doing with Savvion. Believe it or not but I do hold a record of doing most of the ones listed below. Hope you enjoy the read …
Using a BizLogic Process as one page Application
It was a one page reporting application. All that I wanted was to play around with this one page. What did I do? Created a workflow with Start and a Stop workstep, gave it a name and deployed it. It appeared in my Applications page … Bingo.. After a few months I realized I should have used a BizSolo app for it.
In earlier versions of BPM Studio there were no restrictions on what name should be given to the process. We named our process as descriptive as possible – NewAccountOpeningWorkflowForSomeBusinessUnit. When we deployed it on the server it worked without issues. 5 months later we realized that this act of ours ended up paralyzing BizStore Engine, no events were getting processes … and it was too late to rollback. Our database allowed only 28 characters for table names and when BizStore tried to create a table using that name we were screwed.
I always tried to use preconditions when I wanted my workstep to wait. I would monitor dataslots so that when they get set the workflow proceeds. Nice and clean. However later I realized that preconditions are checked almost every minute meaning if I have 10,000 instances waiting, every minute Savvion would check if the dataslot value has been set. My server crashed and was almost impossible to recover it. Then what did I do to resolve it? I made a dummy workstep at each wait state. Wrote a cron job which would check if the precondition which I wanted was met (this precondition was maintained outside Savvion) and once met, complete the dummy workstep. I could scale my server to 40,000 instances. Thanks to a Colleague who suggested this to me.
Enjoying the Pre/Post Script
Pre script and post script are for simple operations. I tried to do almost everything in there. For complex operations, use adapters. They are easier to fix, change and maintain. Sending mails from pre script should also be avoided as in one scenario we were stuck in sending mails .. Neither the workstep was suspended and nor was it activated!
Where to place the adapters?
I loved common resources and tried to place all my adapters in once place. I ended up with restarting production instances, adapters that could not be used across versions, backward compatibility issues.
The adapters should be placed closest to where they need to be used. Savvion supports multiple levels of classpaths and some of them are dynamic. Your process has a “lib” folder which is the highest level of classpath. Try to place your adapters in “lib” itself. “lib” folder has dynamic class loading so you don’t have to restart you server every time a change is made.
However, if you intend to use your adapters across workflows/processes then place them in some common location. We sometime place the inflated folder structure in “ebmsapps” folder itself and then make it available on the portal. For portal you can place your “libs” in the WEB-INF/lib folder of the sbm app (the actual path of sbm.war will depend on which application server you are using).
Using Individuals as performers
Avoid using individuals as performers. People leave the organization, change departments and you would end up doing lot of maintenance. We had to keep one guy to support just changing the performers. Always create groups and assign tasks to groups. Another catch here is that the task naming convention of Savvion is different for users and different for groups. You can avoid lot of confusions by using one of them only.
Handle All my Exceptions in Adapter