Adding attachments to HumanTasks *beforehand*
By Ccasares-Oracle on May 28, 2014
For an demo I'm preparing along with a partner, we need to add some attachments to a HumanTask beforehand, that is, the attachment must be associated already to the Task by the time the user opens its Form. How to achieve this?, indeed it's quite simple and just a matter of some mappings to the Task's input execData structure.
Oracle BPM supports "default" attachments (which use BPM tables) or UCM-based ones. The way to insert attachments for both methods is pretty similar.
With default attachments
When using default attachments, first we need to have the attachment payload as part of the BPM process, that is, must be contained in a variable. Normally the attachment content is binary, so we'll need first to convert it to a base64-string (not covered on this blog entry).
What we need to do is just to map the following execData parameters as part of the input of the HumanTask:
execData.attachment[n].content <-- the base64 payload data execData.attachment[n].mimeType <-- depends on your attachment (e.g.: "application/pdf") execData.attachment[n].name <-- attachment name (just the name you want to use. No need to be the original filename) execData.attachment[n].attachmentScope <-- BPM or TASK (depending on your needs) execData.attachment[n].storageType <-- TASK execData.attachment[n].doesBelongToParent <-- false (not sure if this one is really needed, but it definitely doesn't hurt) execData.attachment[n].updatedBy <-- username who is attaching it execData.attachment[n].updatedDate <-- dateTime of when this attachment is attached
Bear in mind that the attachment structure is a repetitive one. So if you need to add more than one attachment, you'll need to use XSLT mapping. If not, the Assign mapper automatically adds  for the iteration.
With UCM-based attachments
With UCM-based attachments, the procedure is basically the same. We'll need to map some extra fields and not to map others. The tricky part with UCM-based attachments is what we need to know beforehand about the attachment itself.
Of course, we don't need to have the payload, but a couple of information from the attachment that must be checked in already in UCM. First, let's see the mappings:
execData.attachment[n].mimeType <-- Document's dFormat attribute (1) execData.attachment[n].name <-- attachment name (just the name you want to use. No need to be the original filename) execData.attachment[n].attachmentScope <-- BPM or TASK (depending on your needs) execData.attachment[n].storageType <-- UCM execData.attachment[n].doesBelongToParent <-- false (not sure if this one is really needed, but it definitely doesn't hurt) execData.attachment[n].updatedBy <-- username who is attaching it execData.attachment[n].updatedDate <-- dateTime of when this attachment is attached execData.attachment[n].uri <-- "ecm://<dID>" where dID is document's dID attribute (2) execData.attachment[n].ucmDocType <-- Document's dDocType attribute (3) execData.attachment[n].securityGroup <-- Document's dSecurityGroup attribute (4) execData.attachment[n].revision <-- Document's dRevisionID attribute (5) execData.attachment[n].ucmMetadataItem.name <-- "DocUrl" execData.attachment[n].ucmMetadataItem.type <-- STRING execData.attachment[n].ucmMetadataItem.value <-- Document's url attribute (6)
Where to get those (n) fields? In my case I get those from a Search call to UCM (not covered on this blog entry)
As I mentioned above, we must know which UCM document we're going to attach. We may know its ID, its name... whatever we need to uniquely identify it calling the IDC Search method. This method returns ALL the info we need to attach the different fields labeled with a number above.
The only tricky one is (6). UCM Search service returns the url attribute as a context-root without hostname:port. E.g.:
However we do need to include the full qualified URL when mapping (6). Where to get the http://<hostname>:<port> value? Honestly, I have no clue. What I use to do is to use a BPM property that can always be modified at runtime if needed.
There are some other fields that might be needed in the execData.attachment structure, like account (if UCM's is using Accounts). But for demos I've never needed to use them, so I'm not sure whether it's necessary or not. Feel free to add some comments to this entry if you know it ;-)
That's all folks. Should you need help with the UCM Search service, let me know and I can write a quick entry on that topic.