RETURN structure after BAPI call in Workflow

Question: Hi all,

I am doing a simple workflow that sends an email out whenever a purchase requisition is created with a certain material group.

I am using the BAPI BUS2105.GETITEMS to search for items with a specified Material Group. My question is how to I look at the RETURN table in workflow to find an error?

Any suggestions?

Thanks

S.

Answer:
I raised a similair question recently.

I would recommed:

1) Test the method on it's own and check the that it's returning what you expect.

2) Check the that this method is being called correctly and then
check the same from the workflow.

3) Check that all your bindings are working.
One way I know is to set the container debugging/trace on
I think from SWUS maybe SWUD. Print out/page down it will show you
the export/import values and highlight errors that occurr.

If all this proves ok and you are getting values back (I presume your
dealing with a custom development), then you can use can
from SW01 (Business object explorer from SWLD) then select your method and choose exceptions and create exceptions for the method.
Then within the program for this business object you can raise exceptions
and using code that I posted recently in

/forums/viewtopic.php?t=31336

Hope this has helped somewhat.

If not post away and I'm sure the answer is close to hand.

Kind regards,
Mark

Answer:
Hi Mark, thanks for the reply.

I have tested the BUS2105.GETITEMS thouroughly on its own and in the Workflow itself, and I do get the values I expect. My problem is I want to see if there are error values, and this is difficult to do in the workflow being that the RETURN parameter from the BAPI is an internal table. As of right now, I have not done any custom development to the object and would like to avoid that.

Of course, if my only choice is to write a custom BAPI or extend the BUS2105 object I can do that without too much issue.

Thanks again

Shane

Answer:
Hi

I think you could create a new function that calls the BAPI you are using then checks the return table, raises exceptions or a value in a return parameter.
This then forms the bases of a new method that is used in a new task that needs to be place into the WF and the exceptions will form a case path where you can model the actions to take. If a parameter is used then you could use a Case step instead.

TB
Copyright ?2007 - 2008 www.jt77.com