Terminating Running Workflow Processes

[srector]

Does anyone know of a Windchill shell command that would allow me to Terminate a running workflow process?

A couple of errors in our workflows has resulted in way too many unresolved processes. If there is a Windchill shell command available, I thought I could create a script based on a list of the unresolved processes. The alternative appears to be dealing with them one at a time through the UI.

Any other suggestions would be greatly appreciated.

Thanks,

Steve

[MikeLockwood]

You can search for workflow processes as objects, filtered by state then take action from search results.

[rey]

If you want to do it within the windchill shell in bulk, use the command below. Be careful of deleting the ones that are completed because you will lose the routing history.

wt.clients.workflow.engine.DeleteWfProcesses

Use the -help to get more info.

Rey

[ddemay]

Why not use some SQL to mark them terminated?

Deleting them makes you lose a lot of potentially valuable information.


Sent from my Verizon Wireless BlackBerry

[srector]

Dave,

It looks like your suggestion of using some SQL statements might be the best solution. I found the Table/Columns that are affected, and I already had a list of the records that need to be updated. But I have one last question I'm hoping you or someone else can help me with.

Any idea what the Table Columns - ALERTTIME and CHANGESTATETIME represent?

I ran a test where I updated a record using the PDMLink GUI, and then used a tool I have to look at the Windchill schema. This is how I determined what data I would need to update with my SQL commands. Most of the information that changes is pretty straight forward. However I can't figure out what data ALERTTIME and CHANGESTATETIME need. The values are up to 13 digit numerics that seem to be tied in some way to the date and time that the process ends, but I can't figure out how they are formatted.

As a test, I changed a single record on our test server using a sample of the SQL command I plan to use. It seemed to work ok, even without updating my two mystery fields, but I am concerned what the impact will be if these fields are left unchanged.

If you or anyone else has any thoughts on the matter I'd appreciate your input!

Thanks,

Steve

[wpalm_99]

Steve,

Those are both dates. They're stored as the number of seconds from
1/1/1970 but converted to a readable date when displayed on a GUI. With an
sqlplus query, you can format them like this (Oracle)...

to_char(CHANGESTATETIME, 'MM/DD/YYYY - HH24:MI:SS')

It wouldn't be required to change these when you update the state, but you
definitely could do it so you had accurate data showing when the state
changed in the database. If you were changing a lot of them at the same
time, this would help you to recognize which processes were changed as part
of your batch update later. I don't remember the syntax to use with an sql
update, but you can find it pretty easily by searching for "sql date syntax
Oracle/SQL Server".

Regards,
Bill



On Thu, Jul 26, 2012 at 6:35 PM, Steven Rector <steven.rector@drs-sts.com>wrote:

> Dave,
>
> It looks like your suggestion of using some SQL statements might be the
> best solution. I found the Table/Columns that are affected, and I already
> had a list of the records that need to be updated. But I have one last
> question I'm hoping you or someone else can help me with.
>
> Any idea what the Table Columns - ALERTTIME and CHANGESTATETIME represent?
>
> I ran a test where I updated a record using the PDMLink GUI, and then used
> a tool I have to look at the Windchill schema. This is how I determined
> what data I would need to update with my SQL commands. Most of the
> information that changes is pretty straight forward. However I can't figure
> out what data ALERTTIME and CHANGESTATETIME need. The values are up to 13
> digit numerics that seem to be tied in some way to the date and time that
> the process ends, but I can't figure out how they are formatted.
>
> As a test, I changed a single record on our test server using a sample of
> the SQL command I plan to use. It seemed to work ok, even without updating
> my two mystery fields, but I am concerned what the impact will be if these
> fields are left unchanged.
>
> If you or anyone else has any thoughts on the matter I'd appreciate your
> input!
>
> Thanks,
>
> Steve
>

[srector]

Bill,

Thank you so much for your reply!

I thought they had something to do with a date, but I had no idea how to ‘decode’ them. Since I am updating the MODIFYSTAMPA2 & UPDATESTAMPA2 with the current date as I make my changes, I think I will leave the other two alone. I just wanted to be sure that I wouldn’t create trouble for myself down the road if I left them alone.

I really appreciate your help!

Steve