| Author |
Message
|
| dkrawczynski |
 Posted: Tue Jan 14, 2003 12:56 pm Post subject: Resetting Expiration Time when Activity is restarted |
 |
|
Apprentice
Joined: 19 Dec 2002
Posts: 26
Location: Dallas, TX
|
V3.3.2 SP3 Readme mentions that the Expiration/Notification time was not being reset when the activity is restarted. See below.
------------------
17287 IY34879 Expiration/Notification is not reset when activity is
restarted
------------------
I would interept this as meaning the expiration time is reset to reflect the new start time. E.g. The workitem is created on Monday and the expiration time is set to Wed (2 days later as specified in BT exit condition). Then on Tuesday the workitem is force restarted. The workitem should then expire on Thursday and not on Wednesday.
I did some testing. When I force restart a workitem that has an expiration time, I have noticed that:
1) The Workitem.expirationTime() method returns NULL, when before I performed the force restart, it returned the correct expiration time.
2) The expiration time is not changed to reflect the fact that I restarted the workitem as it would seem that it should if I interepted the above PMR correctly. The workitem still expires on the original expiration time. I checked the NOTIFICATION_TIME table and the notification time doesn't change.
My questions are:
1) Why is the expirationTime() method returning NULL after the workitem is force restarted when the entry in the NOTIFICATION_ITEM table doesn't change and the workitem does actually expire at the correct time? The same thing happens if I checkin the workitem and the exit condition I have set fails.
2) Am I interpreting the PMR correctly or is the behavior I am seeing correct? Actually the behavour I am seeing is the behavior I want not the otherway around.
Thanks,
Doug
_________________
Doug Krawczynski
IBM Certified Solutions Expert -
MQSeries Workflow |
|
| Back to top |
|
 |
| jmac |
| Posted: Tue Jan 14, 2003 2:02 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Doug:
I've not played with this at all, but it would seem to me that you would not want the Notification time to be reset in the event of an Activity restart. The Expiration time, I think I would want reset, but not the Notification time.
You should probably post this to the IBM newsgroup and see if one of the developers answers.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| dkrawczynski |
| Posted: Tue Jan 14, 2003 2:22 pm Post subject: |
|
|
Apprentice
Joined: 19 Dec 2002
Posts: 26
Location: Dallas, TX
|
John,
Thanks, I'll post to the news group.
Yes I agree that one should expect the Expiration Time to change when the workitem is force restarted, perhaps even the Notification time since they really mean the same thing (you should be done with the activity by now), but have different effects when the time is reached.
FYI. What I am trying to do is update the container variables for a workitem but I still want to keep the workitem in the same activity, so I use the Workitem.forceRestart2() method. In this case, I don't want the expiration time to change. I can also cause the same effect by setting an exit condition on the activity which fails when I check in the workitem. To make the container values stick, you need to put a data loop connector on the activity.
Doug
_________________
Doug Krawczynski
IBM Certified Solutions Expert -
MQSeries Workflow |
|
| Back to top |
|
|
| jmac |
| Posted: Tue Jan 14, 2003 2:33 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Doug:
I understand exactly what you are doing here, and I understand now why you hope that the doc is incorrect.
If it turns out the doc is correct, you will need to use CO/CI and fail the exit condition. (But I'm sure you already realize this).
Let us know what the Lab says regarding this.
THANKS
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| yaakovd |
| Posted: Mon Jan 20, 2003 11:48 pm Post subject: |
|
|
Partisan
Joined: 20 Jan 2003
Posts: 319
Location: Israel
|
Hi,
In my flow I solved it using Exit Condition, Data Loop Connector and setting Duration and Notification values from container.
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel |
|
| Back to top |
|
|
| nwhi |
| Posted: Tue Jan 21, 2003 12:08 am Post subject: |
|
|
Apprentice
Joined: 19 Dec 2002
Posts: 25
Location: UK
|
Interesting ... I'm just designing a similar mechanism - uisng an expity time to introduce a delay at a set point in a process, having ditched the idea of using suspend functionality because that is really intended to work at the process instance level.
My thoughts were to use a UPES to allow an XML message to reset the expiry time, or, if coming in via the Web-Client, Force Restart (Force Finish can't be used as it ignores the exit condition  )
I can't exactly follow the thread - is the conclusion that ForceRestart2 can change the expiry time (with a changed container value) or not? I'm not interested in notifications but it may be worth summarising your findings - also whether what happens is (according to IBM) what is supposed to happen 
Ah, I've just realised that for the activity to auto-restart I'll need to enclose it in a block, so I might as well use ForceFinish and put the exit condition on the block. That way it will be a brand new instance of the exipry activity so will definitely recognise the changed time value.
_________________
Nick Whittle
IBM Certified Solutions Designer -
WebSphere MQ Workflow V3.4
MQSolutions (UK) Ltd |
|
| Back to top |
|
|
| yaakovd |
| Posted: Tue Jan 21, 2003 3:11 am Post subject: |
|
|
Partisan
Joined: 20 Jan 2003
Posts: 319
Location: Israel
|
I sure we can find few good solutions for this issue. But personally I'm prefer automatic solutions (means "what WF can do by it self"  ) independent from other applications like WEB Client, XML message etc.
And you absolutelly right - in most of cases you need to enclose activity in a block.
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel |
|
| Back to top |
|
|
| jmac |
| Posted: Tue Jan 21, 2003 1:39 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
| nwhi wrote: |
| I can't exactly follow the thread - is the conclusion that ForceRestart2 can change the expiry time (with a changed container value) or not? |
Nick: It is my opinion that this is what can be done, I have not tested this specifically to update the expiry time, but I can say for sure it will update the container field. I think Dougs initial query was trying to determine if IBM had a problem here (maybe only a doc problem). I see he posted to the IBM newsgroup, so we should have an answer soon.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| dkrawczynski |
| Posted: Wed Jan 22, 2003 8:23 am Post subject: |
|
|
Apprentice
Joined: 19 Dec 2002
Posts: 26
Location: Dallas, TX
|
OK. I got a reply from Volker Hoss. He was able to reproduce my two issues and asked me to submit a PMR which I have done.
My testing revealed that the expiration time was not "reset" whether or not it was set by a container value or was hard coded in the Exit Condition of the activity. Maybe someone else can do another test to make sure.
Of course wrapping the activity inside a block does reset the expiration time, but at a performance cost. I personally do not want the expiration time to change if I check-out/check-in the workitem because I don't think that is a case where the expiration time should be changed, perhaps it is when a force Restart is issued, but that also could be a matter of opinion.
What we really need is the ability to programmatically change the expiration time of a workitem to help in some of these special situations. Who wants to put in a PMR for that enhancement 
_________________
Doug Krawczynski
IBM Certified Solutions Expert -
MQSeries Workflow |
|
| Back to top |
|
|
|
|
