Calling smart object using command line

Hi Deb,

You might have to implement a polling scenario in your K2 workflow to check on the status of the envelope for that process. Now, normally you want to stay away from polling scenarios as they can be bad for your K2 server if they are implemented incorrectly. However, if you ensure that your process reaches an asynchronous event so that process stops, dehydrates to the DB and frees up the thread you will be safe. Also, you don't want too aggressive of a polling interval. Think minutes instead of seconds. 

So, there are two ways to meet these goals. You can either A) use a start rule on an activity (which is asynchronous) or B) use a server event (set to asynchronous) or just toss a client event in there. Actually I like the client event idea as it does offer you additional options. You can make the service account or I recommend an administrative group the destination users for the client event approach. The reasoning is that using the client event gives you the opportunity to exercise more control of the process using OOB functionality.

The scenario is after the activity that sends the docusign document have the process route to a wait activity with that client event mentioned above. Set an activity level escalation that will expire the activity after a matter of minutes. At least one line will run from the wait activity to another step that checks the status of the envelope. If the status is unsatisfactory then a line will run back to the wait activity. If things are good, then a line will go onto whatever the next steps of the process may be.

The line that connects the wait activity to the status check activity may or may not contain any line rules. If you choose to leverage the client event with some actions, your line will have an outcome rule defined which also means that you will need to add an "or" condition to the line so that it will be followed in the event that the activity just expires due to the escalation. This will also support an administrator going into a worklist and choosing the force and update check (or maybe cancel all together) all just depends on what sort of functionality meets your needs. Granted, you could use a GoTO in your escalation, but that is a bit brute force for functionality that is already at your finger tips.

This approach removes the need for command lines and queueing tables. Allows each process to keep pace with status with the external events that are happening around it. You could always implement a queueing mechanism if you wanted, but all that depends on what the bigger picture is with regard to the requirements of the project.

Hope this helps.

S.