Generating Workflow Files Part 2
One of the services that I’ve done for a while now through my company, is running design and implementation reviews – spending time with customers getting to understand what they are expecting their Workflow system to do, and then looking at their workflow functional and / or technical design document, or their code that has been written, and providing a detailed analysis of the strengths, weaknesses and opportunities for improvements. One thing that comes up time and time again is that generally the code that has been written to support a Workflow has been written without reference to the Workflow build standards that Oracle wrote some years ago – these have been out there for some time now, but here’s a brief list of what I normally find:
- Procedure signature does not conform to the recommended signature from Oracle;
- Use of hard-coded values for function mode and results rather than using WF_ENGINE constants;
- No logging, or if any is in place, it doesn’t use the Workflow supplied logging package;
- Missing or incorrect error handling.
One thing that this has really got me thinking was about how great it would be if there was some kind of framework that made it easier to write good Workflow code.
So, I sat down and put together a utility to provide well-formatted code, which provides a framework that you can plug in your specific logic. The most important thing that a workflow developer should be focusing on is getting the flow of the process right – here’s where the developer should be devoting their efforts
- Determining what activities are needed in the process;
- Deciding what level of granularity is needed
- Should you have an activity that does lots of processing, a sub-process, or a couple of activities in one process?
- Should you build a series of activities that perform simple steps, or use one activity which has a series of IF conditions in it?
- etc.
- Putting the right activities in the right order;
- Determining error conditions;
- Determining revisit conditions;
- Deciding whether business events can and should be used;
- Deciding whether to defer the process or not.
Instead of which, developers tend to be spending time on writing the PL/SQL to support the Workflow, and not enough time focusing on getting the process(es) right.
I wrote a utility which is designed to help shift this effort from PL/SQL developer onto becoming a Workflow developer. If you install the package attached to this post, a PL/SQL package is installed which can then be used to generate code to support your Workflow. You should define the Workflow process, and this code will then look for a specific Item Type and pick up the PL/SQL activity which you have defined and generate code for you. If you have left any of the activities blank, then the code will create a PL/SQL package with the name of your item type, and procedures within the package named as the internal name of the activity. The code adds logging to the procedures, error handling, and if the activity uses lookup codes, it will also generate the results at the end of the code for you.
It can also update your Workflow for you, if you set it to. So for each Activity where you have not defined the Activity function, the code will generate the code for you to amend to support the business logic, and then update the Workflow with the name of the package and procedure which has been generated to support the process.
The code is copyright TS Fifteen Ltd (the parent company of WorkflowFAQ.com), but I’m prepared to make the code available free for use. If you install the code, then it must include the module header which is supplied with the code. If you make any changes to the code, or have any suggestions for extra functionality, please contact me or add comments below. I will be writing a fuller user guide to add to the module, but here’s the current version.
Leave a Reply