MQSeries.net :: View topic - Assertion Failure on calling activityInstance on a WorkItem

asitschwab · Posted: Fri Mar 23, 2007 2:19 pm Post subject:

Hi Everyone,

I hope you find folks can confirm a possible solution for me.

Scenario:

We're in the process of migrating an application from BEA/Solaris to WebSphere/Linux and in the process switched to run MQ Workflow 3.6 FROM 3.5 on AIX. We switched to run the new "native Java API" (fmcjapi.jar) instead of the binary native libraries (fmcojagt.jar) in 3.5.

Problem:

We ran into problems when the code calls the "activityInstance" method of a WorkItem in an attempt to force the restart of a work time during a work item reassignment.

Symptom:

The code fails with the following error. The error DOES NOT occur when we run using the 3.5 API, but does fail with the new 3.6 native Java API.

The Error and Stack:

SystemOut O -------------------------- Assertion Failure ----------------------------
SystemOut O
SystemOut O Precondition violation !(ActInstIDIsNull() == false) in method >> at com.ibm.workflow.client.util.msg.f
mcmtwit.FmcWorkItemData.ActInstID(FmcWorkItemData.java:178 <<
SystemOut O
SystemOut O -------------------------------------------------------------------------

com.ibm.workflow.client.util.FmcAssertionError: Precondition violation !(ActInstIDIsNull() == false) in method >> at com.ibm.workflow.client.util.msg.fmcmtwit.FmcWorkItemData.ActInstID(FmcWorkItemData.java:178 <<
at com.ibm.workflow.client.util.FmcAssert.precondition(FmcAssert.java:192)
at com.ibm.workflow.client.util.msg.fmcmtwit.FmcWorkItemData.ActInstID(FmcWorkItemData.java:178)
at com.ibm.workflow.client.api.FmcWorkItem.activityInstance(FmcWorkItem.java:429)

Analysis:

Using javap I was able to disassemble the FmcWorkItem (fmcjapi.jar in new native java API) and the WorkItemImpl types in the OLD fmcojagt.jar to see the difference. It's obvious that the FmcWorkItem checks to see if the activity instance id was null or not while the old classes do not.

I reviewed the programming guide for 3.6 MQWF and the guide did elude to the fact that the "old" C/C++ binary API behaved differently in terms of the ActivityInstance.

Question: Does anyone know if this is a fundamental difference between the 3.6 "native Java API" and the 3.5 "binary" API?

Possible Solution:

After going through the programmer's guide and trial/error, expriments, etc. I found that adding a call to "persistentOidOfActivityInstance" on the work item, PRIOR to retrieving the Activity Instance seems to resolve the error. I am assuming that the call to persistentOidOfActivityInstance initializes the activity instance ID on the work item as well as returning the ID.

This was NOT obvious and NOT really well documented in the programmer's guide so I need some confirmations and reassurance.

BIGGG QUESTION IS

Is this the proper procedure for getting the Activity Instance from a work item? Meaning, do we NOW have to call persistentOidOfActivityInstance to initialize the Activity instance ID prior to calling activityInstance to get the Activity Instance object?

The code that seems to work:

public Date forceRestartWorkItemActivity(String workItemId)
throws ConnectionException {
try {
WorkItem workItem = persistentWorkItem(workItemId);
// Calling persistentOidOfActivityInstance seems to
// fix the problem with AssertionErrors that occur
// when we call the activityInstance.
workItem.persistentOidOfActivityInstance();

ActivityInstance activityInstance = workItem.activityInstance();
activityInstance.forceRestart();

return activityInstance.lastModificationTime().getTime();
} catch (FmcException e) {
throw new ConnectionException("Couldn't force restart workItemId " + workItemId, e);
}
}

[b]Any advice, comment is GREATLY appreciated.

Thanks,

Alan
[\b]