The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
Update contact process automatically
Posted: 27 Jul 07 2:33 PM
|
We rely heavily on contact processes and find ourselves making frequent changes to them. Our processes generally run from a couple months to a couple years, so when we modify a process we are left with either the old version of the process running on many (25-75) contacts or we have to go through those contacts and abort the existing active process and start the new version of the process, then push it through to the appropriate step (we usually just leave the old version of the process running). At times we have 4 or 5 different versions of the same process running.
Is it possible to start a process programmatically and specify which step it should start with? If so, we could cancel the old process and start the new process while specifying that it start at the appropriate step.
Is it possible to change the existing process record to use the new version of the process from that point forward?
Any insight you can provide would be greatly appreciated.
Dave McGill |
|
|
|
Re: Update contact process automatically
Posted: 28 Jul 07 6:40 AM
|
When I dissected the Contact process way back when, here is what I found.
When you launch a process, it creates a copy of the released plugin. All of the step information is in the blob of the plugin. The pointer as to where it currently is in the process is in the field NODE. When a history record is generated by a process, you will notice that the field PROCESSNODE is populated. You will also see that field populated in ACTIVITY if it came from a process.
Unfortunately, that is where I stopped digging on that path. I did not want to have to mess around inside the blobs. There are a couple of people who have tackled them for other reasons, and the feedback is that it is NOT for the faint of heart.
So... to answer your questions:
1. There is an article on this site that tells you how to launch a process via code, but it does NOT give you control over what step it is on. It simply creates the "stub" of the process which the engine can pick up and run with.
2. Changing the existing process - no. The alternative would be to make your processes smaller so if something changes, then you can get the new one released out and hopefully have that picked up when it is time to run.
There is a good argument for not changing a process after it is launched. After all if you make a change, it is effectively a "new" process.
Hope that helps....
ws |
|
|
| |
| |
|
Re: Update contact process automatically
Posted: 30 Jul 07 11:13 AM
|
Thank you all for your replies. Unfortunately, you've confirmed what I suspected - the information is in the BLOB field. I expect I'll be taking a closer look at the BLOB field as I can find the time.
The suggestion to use sub-processes is an excellent idea that we already make use of, but we still have processes that hang around for a couple years before they start doing anything again (these are usually sub-processes). We use SalesLogix to keep track of volunteers we send in the field and we have a process that runs when they are getting ready to return. The return process is started at the time the contact leaves for the field, but doesn't do anything until the contact is within 60 days of returning.
Dave |
|
|
|
Re: Update contact process automatically
Posted: 31 Jul 07 7:02 AM
|
Depending on what you are trying to accomplish, you may want to consider using an external workflow engine like KnowledgeSync or TaskCentre.
This way your event can be fired off of a database query instead of something that was queued up months ago. Your logic will always be current as of the time it triggers. You can also break it into independent events if it makes sense, so that if you are planning some kind of drip campaign for contacting them repeatedly as the return deadline approaches, you could set up 60/45/30/14 day versions and have it be an automated email, or push a phone call on to somebody's calendar based on your current rules.
hth
ws |
|
|
|
Re: Update contact process automatically
Posted: 31 Jul 07 7:05 AM
|
Good point Walter....
.. and I've (successfully) developed a method of integrating TaskCentre w/SalesLogix (contact) Processes.
Give me a shoout Dave and we can discuss it.
--
rjl |
|
|
|
Re: Update contact process automatically
Posted: 31 Jul 07 3:29 PM
|
I've done a little testing - this is what I came up with:
1. The BLOB field (DATA) appears to get copied from the plugin at the time the process is scheduled. It does not change as the process advances - thus it does not appear to have any information that indicates which step the process is at.
2. The NEXTSUMMARY and NODE fields specify the step the process is at. The values in these fields remained consistent when I inserted* another step into the process.
So it seems entirely possible to abort all existing versions of a process and start the new version of the process for those contacts using NODE & NEXTSUMMARY to indicate which step the process is at. Of course, it would also be appropriate to add a history record to reflect the change.
If steps were being removed from the process you would need determine which nodes in the new process correspond to the nodes in the old process.
* We start all of our processes with a ESP step. The step doesn't actually make any decisions, but in Architect it allows us to move a branch of a process in order to insert a step, then move the branch back after the new step. Otherwise we would have to delete everything which would come after the new step and recreate each of those steps. |
|
|
|
Re: Update contact process automatically
Posted: 31 Jul 07 3:35 PM
|
| A little more testing showed that editing the existing PROCESS record works (aside from the lack of an audit trail) when I copy the new BLOB (DATA) to the record and change the BASEDON field to reflect the new version of the process. |
|
|
|
Re: Update contact process automatically
Posted: 01 Aug 07 5:25 AM
|
This sounds consistent with what I saw. My explorations were more along the lines of building some more generic tools than trying to address some specific issues.
The thing that stopped me was that the only way that I saw of determining the step information was to look at field contents for a specific process in a specific state. Have you cracked how to generate the "processnode" pointer?
One word of caution - if you make a mistake on a process that causes it to hang, then no other processes will execute until you remove the bad one.
ws |
|
|
|