cancel
Showing results for 
Search instead for 
Did you mean: 

Use of a Check FM in SRM7

keohanster
Active Contributor
0 Kudos

Hi all,

We’re upgrading to SRM7 (technical only) from SRM5 and using our old Custom Application Controlled Workflows.

We're on EHP2 for SAPSRM 702.

We’ve always used a Check Function Module in the Event Linkage table to prevent multiple workflows from kicking off for Purchase Order Change Versions  if the same GUID is already involved in an active workflow process. 

So if the Check Function module (referenced in SWETYPV) finds an active workflow using that PO GUID, it exits gracefully with our friendly exception NO_WORKFLOW.

In SRM7, however, this is interpreted as something completely different in the PDO layer…

A very nasty error is displayed to the user ("Cannot get process info; function throws exception Workflow Not Found" and "PDO Layer error")

Has anyone else had to change their methodology of using Check FMs in SRM?  I know I can put a task in the workflow to check for other flows on the same GUID, but Check FMs seemed to work so nicely before. We could probably also put this check in the Doc Check BADI. 


Related to any other searches on SCN I have done, the business object BUS2201 is generated and fine, the workflow customizing has been done and is fine.  OSS notes 1531709 and 1442808 are for an earlier release, and OSS 1422084 was related to Quotations. 

Thanks in advance,
Sue

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

Interesting question. Are are you absolutely sure that the error that you are now seeing is appearing because of the check function module (what if you remove it from SWETYPV)? I have always believed (perhaps wrongly) that the whole workflow starting process with an event is an asynchronous process. The application triggers the event, but it does not know whether a certain workflow was started (well, e.g. the event creating function gets the "At least one receiver found" message, so I guess it knows if something was started or not). This is a problematic area if you want to use events for starting workflow, but you also need to know the work item ID of the workflow started.

Anyhow, I have no experience of workflows in SRM7, so I have no idea what is going on or what has changed. I would probably find the place in the code where this error is raised (by doing some debugging), and then make my assumptions if the problem can be "fixed" with some trick, and if not, then use some other method instead of the check function (placing a new step in the beginning of workflow being the first option).

Regards,

Karri

Answers (1)

Answers (1)

I042439
Employee
Employee
0 Kudos

Hi Susan

I do not have an answer for you..... .... try posting your question to http://scn.sap.com/community/srm/workflow-and-user-vendor-org-management .... there you will get SRM experts too 🙂

Regards,

Modak

keohanster
Active Contributor
0 Kudos

Hi , ,

Thanks for the feedback.


Modak, I have considered posting the the SRM Workflow Forum, but definitely did not want to double post!

Karri,  I have not debugged into the guts of SRM to determine specifically if it's the Check FM, but I can make reasonable assumptions... I can see the Check FM throwing the exception, and if I remove the Check FM, and make the exact same change to the exact same PO,

I no longer get the error

I am going to look into using the Doc Check or if necessary, the workflow itself.


Thanks for your feedback!
Sue

Former Member
0 Kudos

OK, I see.

It's many years since I worked with SRM. One thing that I remember was that it seemed that lots of things related to workflows was supposed to be done with the BAdIs. (If I tried to do certain changes to the workflow, I ran into some strange errors that I was not expecting.) Perhaps this is one of those things. Perhaps the code inside the check function should be in one of the methods of certain BAdI. This is just speculation from my part, and probably you are already fully aware of this possibility and know there isn't such a BAdI...

Kind regards,

Karri