Quirks in 4.6c with generic instantiate?

[Hilsbos, Margaret A]

Hello again WUGers,

My latest QMSM problem seems like it should be a silly little thing, but it has me tearing my hair out.

We are on 4.6c. I want to instantiate ZQMSM based on values returned from BUS2080.GETDETAIL. So I concatenate the notification and task numbers into an element ZQMSM_key that has the definition SWOTOBJID-OBJKEY, and bind that to a task based on SYSTEM.GENERICINSTANTIATE.  The task has the default object type of ZQMSM, and the element ObjectInstance references the object type ZQMSM. Of course I have specified the binding for ObjectInstance back to my ZQMSM object in the workflow.

When I test the workflow, the step completes error-free, but does not return ZQMSM.  ???

I can take the value for ZQMSM_key directly from the container in the workflow log, paste it as my input value in SWO1 test of the genericinstantiate method, and it works just fine - the correct ZQMSM instance is returned.

Does anyone have any idea what I might be doing wrong? I have used generic instantiate successfully a few times in a 620 system, and I thought it was pretty simple. I'm wondering if there are any quirks to using it in 4.6c.  (I even went home last night thinking, maybe the magical midnight buffer strikes again....alas, it still does not work this morning.)

If nothing obvious springs to mind, are there any debugging techniques I might use in this situation?

Thanks for any help you can provide!

(and now it's time to go try the solution Mike gave me yesterday to my other problem... :-)


Margaret Hilsbos
Day & Zimmermann