Adding attachments to HumanTasks *beforehand*

Posted by ccasares on Oracle Blogs See other posts from Oracle Blogs or by ccasares
Published on Wed, 28 May 2014 22:16:33 +0000 Indexed on 2014/05/29 15:36 UTC
Read the original article Hit count: 423

Filed under:

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 [1] 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[1].name  <-- "DocUrl"
execData.attachment[n].ucmMetadataItem[1].type  <-- STRING
execData.attachment[n].ucmMetadataItem[1].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.:

/cs/groups/public/documents/document/dgvs/mdaw/~edisp/ccasareswcptel000239.pdf

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.

© Oracle Blogs or respective owner

Related posts about /BPMN