Workflow Attachments

Todd_Martindale

When initiating a workflow from Content Server, the user is able to add an attachment that is not already in Content Server (upload a new document).

Through EWS, it seems like the only way to attach a document to a workflow is to have the document already in the system.

We need to be able to duplicate the functionality that is available through Content Server's web interface.

We have discovered that when attaching a document through the web interface, looking at the dtree table in the database, it looks like the ParentID of the attachment is one more than the MapID of the initiated workflow. For example, if the MapID is 87926, the attachment's ParentID is 87927. With this information, can we initiate a workflow using EWS and then upload a document using a ParentID that is one more than the MapID? Can we count on it always being one more than the MapID?

 

Appu_Nair

Going by numbers for objid's can be a real tricky proposition .I have seen livelink instances were the enterprise instance is not 2000 as always assumed in livelink by many programmers.

In looking at the service implementation I see this as you state

//
// StartProcess loads the ProcessDefinition (Workflow Map) identified by the objectID in the
// ProcessStartData SDO and starts the workflow processes with the specified Title in ProcessStartData.  
// An optional list of attachment objectIDs (already created in Content Server) can be passed to this
// method and they will be copied into the workflow process attachment folder.  Similarly, an optional list
// of member IDs can be passed into this method to be mapped to roles in the workflow.

 

Old LAPI had this feature so I would urge you to ask OT why it cannot be built into its replacement code stream.Or you can do that as well.In the interim one could start the workflow with EWS,get its attachment id and into that attachment put a doc using docman operations....

Just a thought and trying to help ...