Check FMs vs conditions on triggering (start) events

[Former Member]

On page 6-17 of the BIT610 course manual, it warns that if you use a check FM on a start event for a workflow, then inside the check FM you may not get the attribute values you expect if the event is the "created" event of a business obect. (This is because some business objects are created before the actual DB commit, and when this is the case, the check FM may find nothing in the DB for the object attributes it's trying to check).

So here's my question.

Apart from actually testing, how can you tell whether it's safe to code a check module for a "created" event?

Reason I'm asking is that I'd like to remove some "start conditions" on the triggering event of the workflow itself and put them in a check FM. But how do I know this is safe (other than actually testing?)

I have a follow up question to this one, but want to get this one straightened-out first.

Thanks

djh

[sudhindra_chandrashekar · Accepted solution]

Hi David,

I would never have a start condition on my workflow. Especially with virtual attributes I take special care. Till date I have all the conditions inside my workflow builder and I do not even code my Check function module.

As far as my understanding goes it is pretty hard to determine which one of the business objects has a problem. It is deeply embedded within the transaction as to when and where the event is raised. We all understand that a Commit is necessary for the SWE_EVENT_CREATE which is used by many of the standard transactions. Usually a commit is done at the end of a transaction to save all the data that is in the buffer for that LUW. So it is hard to tell whether the data gets committed to the database first or the event gets raised.

Hope this helps in your design,

Sudhi

[former_member181923 · Accepted solution]

Hi Sudhinra -

Thanks for taking the time to reply - I suspected the correct answer is along the lines you just gave.

But here's the point - suppose you test and find out that the object attributes you need ARE set properly in the DB when the CREATED event fires.

Then I'm pretty sure it's the case that some overhead can be avoided by taking the start conditions off of the workflow event and putting them in a check FM.

Anyway, that's my second follow-up question, which I'll post separately, so that points can be awarded separately. So don't offer your opinion here - wait for the new thread (if you care about the points, which you may not)!!

Best regards

djh

[pokrakam · Accepted solution]

Sudhindra,

That is not correct, you should use start conditions wherever possible rather than starting a WF!

Triggering a WF invokes the workflow runtime system - RFC, an additional dialog session, associated logging and table entries. This is a massive performance hit if you're creating 10,000 documents per day and only actually running a WF for 1000 of them.

SAP provided events are actually the mechanism used to guarantee that a DB commit is complete. Think about it - if it's not available at start cond time, what's to guarantee that it's there in the first step of your WF??? V2 updates can take 10 minutes or more - I've seen 2 hour backlogs.

No, start conds in the event linkage are definitively the way to go. The precaution most likely relates to custom events which people sometimes coding in userexits. This is a different design issue.

Cheers,

Mike

[KKilhavn · Accepted solution]

Not meaning to cause problems in SAP here, but you got a recommendation from one of SAP's employees that contradicts advice previously given by another SAP employee in the mailing list for workflow questions.

Some arguments for using start conditions:

- MUCH easier to understand

- handles amounts in different currencies for you (note: translation date=syst-datum)

- can be maintained by non-programmers

- can be maintained in production systems if the configuration is as it should be

Check functions can be necessary, but for simple conditions the start conditions have advantages. So unless you experience problems, why not use start conditions? Even if you experience problems with commit delays you would probably solve these in most cases by enabling the event queue for your linkage. Only if the delay is significant, many seconds, would there still be problems.

I rarely worry about overhead when working with workflows. If there is a performance problem, the solution design is the most likely problem and will usually have the largest potential for improvement. Workflow solutions also often involve people. I have yet to meet a person that works nearly as fast as the application server for workflow solutions, so performance has never been an issue. Load, on the other hand, can be an issue, and we had to rewrite a solution significantly once, but then it was the solution design that was the problem, and we reduced the number of workflows started by approximately 70% by changing the design. No start conditions or check functions involved.

PS: You can award points to more than one reply - so there isn't any need to start a new thread as long as you stay on topic. For new topics on the other hand.... It is better to start two threads than asking two unrelated questions in the same thread.

[pokrakam · Accepted solution]

Good points. On the matter of overhead, this should always be taken in context - if it is a manually processed object then I don't worry about it, but a BKPF or MSEG event will have a performance impact if a workflow starts for every material document posted. I've seen a batch process grind a system to a halt because triggered 2000 workflows and ate up all the dialog sessions for the next half hour. Start conds will prevent that if the WF's aren't necessary.

Here's something else I thought about: on the matter: Why only on "Created"? Surely if updates are an issue then an INSERT is no more special than a MODIFY? If anything having blank data (create incomplete) is preferable to having wrong data (update incomplete).

The SAP doco on this also backs up the claim that if a standard event fails you've got an OSS issue on your hands. See quotes from the SAP help below.

Cheers,

Mike

"Ensure that the event is not created before the relevant object is written to the database. Otherwise a workflow could be set to status error when started because the object required cannot be found."

"Note that events say something about object status changes that have actually occurred. Therefore ensure that the event is not created until the relevant status change has taken place. For this, the function module for creating an event should be called in the same logical unit of work (LUW) as the one in which the status change is made."

"The change document is written when the change is updated. The procedure described, putting the event after the logging, ensures that the event is not created until the change has actually been made."

[KKilhavn · Accepted solution]

> On the matter of overhead, this should always be taken in context - if it is

> a manually processed object then I don't worry about it, but a BKPF or

> MSEG event will have a performance impact if a workflow starts for every

> material document posted.

Not to mention if a workflow is started for every document item that is posted.

> I've seen a batch process grind a system to a halt because triggered

> 2000 workflows and ate up all the dialog sessions for the next half hour.

Precisely why we had to rewrite one of our solutions

The problem should of course have been discovered in the test phase, but when things are rushed, **** happens more frequently than when one is allowed proper time for testing, and testing is actually done.

> Start conds will prevent that if the WF's aren't necessary.

That's our problem. They wanted to be able to prove why a document was determined to not require approval, so we could either create a separate log for that or use the workflow log. The workflow log it is, meaning we start around one million workflows per month for this solution alone - and that's after the rewrite which reduced it by 70%.

Most of the workflows, I would guess around 95% but I don't have access to the information anymore, complete in less than 15 seconds because the document is not relevant for approval. This could have been determined using a calculated attribute, but then we wouldn't be able to prove exactly which rule triggered the decision.

Agree completely on your other thoughts about the DB update not being a problem only for new documents. In a way the updates are a bigger problem, because the workflow will probably appear to function. When the document does not exist in DB the workflow fails and everyone understands there is a problem.

[former_member181923 · Accepted solution]

Kjetil - I've upped your points to 10 and marked this thread closed because you answered my question completely in a different thread. In that thread, Mike says:

*******************

Kjetil,

...

As you've correctly established, even the SAP documentation contradicts their nonsense. A start condition is implemented as a check function, so there is no difference; and NO workflow is started at any time if they fail.

Cheers,

Mike

*******************

The key here is that a start condition is implemented as a check function. If this is the case, then there can be NO overhead difference between them - only a difference in the complexity each one can handle...

Thanks very much to both Mike Kketil for finally clarifying this completely.

Dave

[sudhindra_chandrashekar · Accepted solution]

Hi,

Just read all the responses and definitely helped me a lot. I have done almost 200-300 workflows till date and the usual pattern that I use with start conditions is as follows:

1. Have the start condition and then if it does not work then handle it within the workflows.

2. Take special care while handling Virtual attributes because these can act cranky sometimes.

Usually I take the path of testing and then deciding which development roadmap I have to use. The question from David was however "How can we know whether to use Check FM even without testing", so my answer was based on that.

Mike's points well taken and I do understand that triggering the workflow for all the documents is certainly a performance hit but to have a solution working and foolproof rather than not to have it working at all is more important to me! This is how I think.

Best regards,

Sudhi

[pokrakam · Accepted solution]

Hi Sudhi,

Sorry, then I misunderstood you when you said "I would never have a start condition on my workflow.", which I interpreted as advising people to "Don't ever use start conditions".

I was a little horrified at reading this, hence the perhaps a little strong reply. In summary:

If it's a SAP event or one you created using the standard SAP methods for generating an event (e.g. change docs) then you should be OK. If not then it shouldn't be your problem - OSS.

The exceptions are virtual attribs that access data outside the object, or anything involving events/updates you coded yourself in exits and the likes. Either you need to understand exactly what the system is doing (not always an option) or leave it as uncertain and have a little safety margin at the expense of performance.

Cheers,

Mike

[Former Member]

hello Rob ,

there is a difference between checkfunction module and start condition.

Before the workflow is triggering can u able to check the conditions in startcondition.The startcondition can check the condition only after the workflow has been triggered.

But in check function module u can check the condtion before the workflow got triggered

[former_member181923]

Hi Catherina -

I also thought the same way as you, but after reading the comments, I'm not sure now.

I originally thought that a start condition could not "stop" a workflow until after the workflow had been loaded by the WIM.

But the discussion here seems to indicate that a start condition doesn't invoke any more overhead than a check function. And in that case, it would make sense to use a start condition when the logic is simple enough.

Dave