Search for a command to run...
I'm a developer that has spent most of his professional career in the Oracle world with extremely brief detours into JAVA, JavaScript, C#, shell scripting and Python.
Current areas of expertise are Oracle APEX, Data Model Design, PL/SQL, Oracle REST with a little performance tuning thrown in.
No comments yet. Be the first to comment.
Quite some time ago I was asked by a customer how we could track the changes to a row over time. They had a couple of very important tables for which they wanted to keep track of who changed what. The interesting thing was that they were not interest...
There are many times when you're coding an application where there is a requirement for seed data that is required for the system to run correctly. If the seed data is changed or missing, some programming functions will fail due to the missing data. ...
This article was first published on blogs.oracle.com in September of 2019. Not long after it was published I was made aware of a couple of security flaws. However by that time the underlying blogging platform Oracle was using had been migrated and I ...
In honor of #JoelKallmanDay, I thought I’d break back into blogging after a long hiatus with an update on some of my more popular posts of the past – Oracle APEX and Workflow. In January of 2018, I kicked off a little personal research project. The g...
After my initial post about this, I had a discussion with John Snyders of HardLikeSoftware fame, and it turns out there is a better and more efficient way to maintain the tree state. While what I outlined definitely works, what follows is the “prefer...
In my previous post I mentioned that I’d be developing a non-trivial, real-world application from scratch and approach it in the same way I would if I were doing it for a paying client. The first step in that direction is to gather requirements and define the project:
There are obviously loads more questions that we need to ask, and answer. But lets start with these three. The rest of this post will provide a broad outline for the project, where I’m going to try to set the boundaries, and why I chose this specific idea to tackle.
Since my early days working with the Oracle database, all the way into my tenure with Oracle APEX, workflow has been something of a conundrum. When most people see or hear workflow it usually goes one of two ways: They think of something specific to their business and therefore fairly concrete (in their minds at least) or they think of something wildly generic that will suit every case that ever existed and ever will exist.
As a long time consultant programmer, every time I discuss workflow with a client it usually goes something like this.
Client: We need some sort of workflow engine so that we can track the progress of Process A through its multiple steps.
Me: Ok, I’d love to understand more about the steps in this process, how complex is it?
Client: Oh, very complex. There are multiple steps, various people involved, various decision points that may change the outcome and we have restrictions on how long the process can take.
Me: How “static” is the process? Do the steps and process change over time or has the process been fairly stable?
Client: It’s fairly stable, but we’d like to be able to react quickly to new business drivers that may push changes to the process. We pride ourselves on being a nimble company and that’s what keeps us competitive.
Me: Understood. Sounds like you need a full-fledged workflow engine that allows you full flexibility to adjust process definitions. There are a number of commercial solutions out there. Are you interested in looking at any of them?
Client: We’ve actually done a bit of research and the commercial solutions are either too complex, too expensive or too hard to integrate. We’d rather have something written that suits our specific needs.
Me: [ … silence with a blank expression … ]
At this point it turns into the age-old discussion of the value of buy vs. build. The cost of maintaining home-spun software and the value of a supported product. If they truly choose to go down the “roll-your-own” path, then there is inevitably the discussion of re-inventing the wheel.
In my experience, more times than not, the client abandons the entire idea of a flexible workflow engine and ends up hardcoding the process steps into whatever platform they’re using to develop. I can’t tell you how many clients I’ve built code for that, as soon as the process steps need to change, they’d have to rip apart and rewrite.
There have been a few clients over my 30+ years of doing this that, while they didn’t want to buy a huge workflow package (feeling it was overkill), did want truly flexible workflow. For these customers we’d develop something that was flexible enough to suit their business model, but it was so tightly integrated to their core system that it really wasn’t usable by anyone else in the company.
One (1!) customer let me convince them to implement PL/FLOW and integrate that into their system. This worked well, and they were happy with it for quite a while. Then when they wanted to integrate it with another system, they were so confounded by the whole thing, and because they weren’t able to get support (and didn’t want to pay me to help them) they ripped it out. I’m still not sure what they did to replace it, but alas it is not my problem now.
What do we take away from all this? Workflow is not straight forward. It’s hard – hard to understand, hard to implement, hard to integrate into existing systems. It’s just hard. So this, in essence, defines the answer to the first question I outlined above. What is the main purpose of the project and what need does it satisfy:
Lofty goals indeed, but that’s the gist of what I’ll be trying to do here.
As I mentioned above, there are quite a few commercial, scalable and flexible workflow products out there on the market. Just Google “Workflow Engine” and you’ll get north of 6,200,000 entries. Google “Free Workflow Engine” and that number gets cut in half. Still a significant number, don’t get me wrong!
So why build Yet Another Workflow Enginei? There are a few reasons.
This brings us to the second question in the list above. Are there real and artificial limitations placed on the project?
First lets address the real limitations:
Now what about those artificial limitations:
i. Hmm.. YAWE might be a great name for the end product! I shall build a workflow system and it shall be called YAWE!
The last of the three questions is probably the easiest to answer: What technologies will be used to satisfy the requirements? Why?
Technologies? Oracle Why? You have to ask?
Now having said that I can take a swipe at what I’ll likely use for each major area:
Tools:
Technologies:
These are obviously open to change and influence by you, the reader. But I think that’s a reasonable estimation of where we’re headed.
Workflow is my chosen project. Its been an idea that’s been stuck in my head like a bad 80’s song for years. Now I finally get to set it free.
While you’re not likely to dissuade me from going down this path, I’d love to hear your thoughts on this choice and the topic in general.
Until next time…