Quirks in 4.6c with generic instantiate?

Thu Dec 1 09:07:27 EST 2005

Jocelyn,

Thanks for the suggestions. As it turned out, I was able to get this to work just by creating a new task from scratch.  (I posted a follow-up last night to that effect)

Comparing the tasks screen by screen I saw no difference, yet one worked and the other didn't.

The task that didn't work was copied from delivered task TS01200205. 

Looking at it again this morning, I checked the binding task <> method. THERE I found a difference: the broken task has a binding defined, the working task does not.

I deleted the task <> method binding and now the "broken" task works. So apparently that was the problem all along. 

I wouldn't have picked this up before because I am unclear when a task <> method binding should be used and when it shouldn't. I wouldn't have thought it would do any harm, but apparently it can.

So, a little more knowledge gained, and on to bigger problems .... ;-)

Margaret

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu]On Behalf
Of Dart, Jocelyn
Sent: Thursday, December 01, 2005 4:15 AM
To: SAP Workflow Users' Group
Subject: RE: Quirks in 4.6c with generic instantiate?

Hi Margaret, 

Most likely cause is the concatenation is not correct. 
Make sure you have checked for conversion exits on the fields, e.g. in
case you need to sort out leading zeroes or similar. 
No error may just mean no existence check so could be a red herring.  

I take it you have tested the method on its own - have you tried testing
it within a single standard task? 

Regards,
Jocelyn Dart
Senior Consultant
SAP Australia Pty Ltd.
Level 1/168 Walker St.
North Sydney 
NSW, 2060
Australia
T   +61 412 390 267
M   + 61 412 390 267
E   jocelyn.dart at sap.com
http://www.sap.com

The information contained in or attached to this electronic transmission
is confidential and may be legally privileged. It is intended only for
the person or entity to which it is addressed. If you are not the
intended recipient, you are hereby notified that any distribution,
copying, review, retransmission, dissemination or other use of this
electronic transmission or the information contained in it is strictly
prohibited. If you have received this electronic transmission in error,
please immediately contact the sender to arrange for the return of the
original documents. 
Electronic transmission cannot be guaranteed to be secure and
accordingly, the sender does not accept liability for any such data
corruption, interception, unauthorized amendment, viruses, delays or the
consequences thereof.
Any views expressed in this electronic transmission are those of the
individual sender, except where the message states otherwise and the
sender is authorized to state them to be the views of SAP AG or any of
its subsidiaries. SAP AG, its subsidiaries, and their directors,
officers and employees make no representation nor accept any liability
for the accuracy or completeness of the views or information contained
herein. Please be aware that the furnishing of any pricing information/
business proposal herein is indicative only, is subject to change and
shall not be construed as an offer or as constituting a binding
agreement on the part of SAP AG or any of its subsidiaries to enter into
any relationship, unless otherwise expressly stated. 

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Hilsbos, Margaret A
Sent: Thursday, 01 December 2005 1:47 AM
To: SAP-WUG (E-mail)
Subject: Quirks in 4.6c with generic instantiate?

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

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug