BPM Document Integration with Content Management Framework Folders
BPM Document Integration with Content Management Framework Folders
By: John Schleicher | Sr. Technical Architect
Oracle BPM (workflow) of both BPMN and BPEL flavors offers document integration as basic functionality as well it should. Human workflow is inherently tied to documents that support the activity in question. To provide this capability workflow accommodates documentation (aka attachments) in task based schemas and within the User Interface forms that support it. Workflow programs can pass documentation to tasks by carrying them in the schema as files or URL references. The BPM form documentation component then exposes those documents for viewing and allows for the addition and deletion of the same.
The default storage of the documents is made within the underlying workflow database schema but administrators can configure the workflow engine to leverage the content management data store as an alternate location. Information about this can be found in the SOA Administrator’s guide and numerous blogs.
The content storage alternative offers storage improvements over the original configuration but still is fairly limited in ability as compared to interacting with documentation within the content system itself. Though the ability to view existing documents, add or delete documents and define a few optional criteria exists with the BPM based user interface, more sophisticated elements of content such as managing revisions or viewing history are not available. You can also search for content documents and attach them to the workflow through the BPM attachments UI component. This may offer some integration but ultimately requires the users to be accessing both content and BPM interfaces in a fairly disjoint fashion to be somewhat effective. Shouldn’t there be a more effective mechanism?
When faced with a requirement to migrate a manual workflow system based on file folders the answer became obvious. If the workflow documentation was segregated into logical folders within content (basically into framework folders) then workflow could access the content UI based on that workflow associated folder. So instead of using the existing BPM document component, the URL specifying the framework folder was substituted as a go button or link in the BPM form which would render the content UI for that folder with the document listing. Adding new documents can likewise be provided by another go button tying it to the Add capability of the content URL so the users can click a button, add a title, browse and upload a document to the folder and workflow.
There was initially some concern over the lack of a document listing on the BPM form. The concern was easily allayed however by the common activity of separating the tabbed content document listing from the BPM form and simultaneously displaying it on a dual monitor system. Power users have ready access to the document listing with this configuration (as shown in the below diagram). Also the separation of the listing offers more real estate for the rest of the form. For my case I extended the comments component into the vacated space formerly reserved for the list of documents.
There are other benefits to leveraging the content UI straight from workflow. The first of course is the ability to leverage document versioning. Secondly, document access beyond the workflow lifespan is easily possible, as well as applying search metadata against the folders and documents to allow non-workflow association to be realized. For the out of the box workflow/content integration when workflow is complete, how do you get to those documents? For the direct integration outlined here, you are already creating the folder, so you can also apply some metadata for searching folder contents and you have the ability to find workflow documentation well beyond the life of the workflow.
This new configuration has some coordination required between workflow assignees and content roles. Workflow users require sufficient privileges to view, add/delete, and update content. This administration is simple enough and can be tied to the framework folder that is associated with the root element for the workflow activity.
So what could be classified as a drawback? For one, the simplistic ingestion of documents into the storage requires a bit more programming. The workflow system (whether BPMN or BPEL) must now leverage the UNIVERSAL_CREATE mechanism of content’s GenericSoapPort webservice to create logical folders for the workflow and then create/upload any documents coming into the workflow. The logical folders must be oriented around a unique key to be able to reference the folder throughout the workflow as the form must provide the specific folder’s URL for access of documentation. Also applying metadata for post workflow searches is a small overhead as well. So ultimately this is a little more complicated than the original but not prohibitively so.
So I have outlined a relatively straightforward integration of Oracle BPM and Content storage for workflow documentation. If your BPM project is aligned on folders or another logical key it may be an option for your documentation access.
BPM Workflow tab adjacent to Content Framework Folder Listing
