In OIM pre 11g you were basically forced to implement decently complex approval workflow in Java code as the built in workflow editor simply didn't support more complex workflows. Coding the approval workflow was not a big problem if you had basic Java programming skills but it did mean that the person that did the approval configuration had to be a programmer.
Implementing in code also meant that the implementation really lacked agility. You do need to test code more extensive than configuration and that means that your cycle time will be longer than if you could create approval workflows through configuration.
In OIM 11g approval workflow configuration is done through BPEL. This means that you can get a business analyst with BPEL skills to do most if perhaps not all of the approval configuration and there are many more people with BPEL skills than OIM approval API available on the market.
It is clear that this was a long overdue improvement of OIM that will help customers both to have quicker and less painful implementations as well as improving the maintainability of OIM.
One thought that kind of strikes you is that this may be the first step to move more and more of the workflows in OIM from the mysterious objects in the design console and the Java API code into the world of BPEL. Interesting concept isn't it?
I am pretty sure most OIM having a hardtime implementing SOA BPEL in OIM. You know what I mean, notifications... clustering are big problems in this area. I am pretty sure they modified the flow.. in R2. "Catalog" thing...
ReplyDelete