Workflow - Start Condition Failure

[Former Member]

Hi All,

I am trying to put a start condition on a workflow of mine. I just want to check if an order type = PM01 or PM03 and not 0010.

I have my start condition set-up but every time I run it I get this error in my event log:

Operator 'EQ': The value of the left operand cannot be determined

  (  " PM01 or PM03 
     &Maintenance order.Order type& = PM01 
     or    &Maintenance order.Order type& = PM03 
  ) " PM01 or PM03 
  and    &Maintenance order.Plant& u2260 0010 

The funny thing is if I go to SWUE and kick off the even it passes the start condition fine. So therefore I think there is an issue with my container being passed to the start condition.

Is there anyway I can fix this?

Many Thanks For Any Help Provided,

Colm

[Former Member]

Hi Mike,

Here is the setup in BSVW:

ORI BUS2007 RELEASED Released

and the status restriction is this:

I0002 REL Released

Thomas,

I know what you are saying about the event triggering before the information has been written to the database and I am pretty familiar with the concept. What I can't understand is that, even if the information isn't written to the database, why is the container still not populated?

I would have thought that the container get's passed to my event, my start condition checks the container, and the workflow proceeds based on the value in the container.

I understand that in real terms, my event is kicked off (lightnening) and then the information gets written to the database (thunder). But I would have thought that my container is available in the lightening so why shouldn't the check work.

Thanks again for all your help!

Colm

[pokrakam]

>

> Lightening is the Event.  Thunder is the Update.
> 
> You see the Flash of the Lightening before you hear the Sound of the Thunder.

An interesting analogy, and one that would apply if events are not correctly set up. In theory, events are exactly the mechanism by which we can get around the update delays because they should be designed to be fired right at the end or together with the final update - i.e. events should be part of the thunder, or even an echo of it.

From the [SAP Doco on Change Documents|http://help.sap.com/saphelp_nw70ehp1/helpdata/en/cc/d40b37da4de72fe10000009b38f889/frameset.htm]: The system then creates the event whenever a change document is written for the change document object. 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.

The event-before-DB-update situation is often the case with custom events raised incorrectly in code or userexits, but should not happen when using standard methods such as status management. Note I say should... and if it doesn't then it should be a case for OSS.

>

> Hi Mike,
> 
> Here is the setup in BSVW:
> ORI	BUS2007	RELEASED	Released
> 
> and the status restriction is this:
> I0002	REL	Released

In this instance, using config to raise events based on SAP system statuses there should definitely not be any update issues. In theory anyway. I would suggest testing this in isolation: Create a small workflow with the order as an importing container element and trigger it using the same event. If the object arrives in the WF then the start condition is a case for OSS. One exception would be if you are using custom fields which are being updated in an unusual way, but this is obviously not the case for a document type.

[Former Member]

Hello Colm,

You say:

"I would have thought that the container get's passed to my event, my start condition checks the container, and the workflow proceeds based on the value in the container."

As Thomas said, not everything gets placed in the container; in the case of a BOR object only the type (eg BUS2009) and the key make it into the container. These are then used later to fetch the attributes. So it makes a big difference if the start conditions are based on key or non-key fields and the data hasn't been saved yet.

But generally, as Mike said, this isn't a problem in standard SAP, it's usually only when it's been custom made and someone forgot a commit somewhere.

regards

Rick Bakker

Hanabi Technology

[Former Member]

Mike,

Your intuition is incredible. My experience came from debugging through SD code and learning that the event was indeed being triggered in a user-exit within subroutines of SAPMV45A/MV45AFZZ.

So that I don't muddy the waters of this thread, let me ask all readers to set my contributions aside as sort of an addendum to the thread.

I on the other hand am going to take this opportunity to familiarize myself with BSVW.

Thanks for your contribution Mike.

Regards,

Thomas Carruth

[Former Member]

Mike,

I think you're on to something with the "echo" addition to my analogy. Suppose the SD code looks like this pseudo code

CALL FUNCTION 'UPDATE_SD_DOC' IN UPDATE TASK   *pseudo FM name.
CALL FUNCTION 'WRITE_CHANGE_DOC' IN UPDATE TASK *pseudo FM name.
CALL FUNCTION 'SWE_EVENT_CREATE_FOR_UPD_TASK' *actual FM name.
COMMIT WORK.

The effect of the COMMIT WORK will be to hand-off all three FM's above to the Update Process. The Update Process in turn executes the FM's in the order they were called originally.

A COMMIT WORK would again have to be called at the end of the update in the Update Process in order to commit the true application data.

Is it possible that the Thunder/Lightening/Echo concept is happening within the context of running in the Update Process?

And what way might system performance and load be contributing to the problem. What load is the Update Process under? What seemingly worked fine in a development system starts to act the way Colm is describing only when transported and executed in Production.

Ok, I think I'm done.

Edited by: Thomas Carruth on Mar 27, 2009 7:06 PM

Edited by: Thomas Carruth on Mar 27, 2009 7:06 PM

Edited by: Thomas Carruth on Mar 27, 2009 7:07 PM

[pokrakam]

Hi Thomas,

Your earlier explanation is perfecty valid and is a common problem people have with workflow events. However I'm not sure why you say that another COMMIT WORK would be required? The effect of the COMMIT WORK is to submit all the queued updates as a single LUW which either succeeds or fails. Raising the event is part of the LUW, so it too is subject to a rollback if anything in the LUW fails.

On a more technical level, this means that from an outside perspective nothing happens until the transaction is successful. While a LUW is in progress (you could be updating a million records in a single transaction), everything else sees the old data. Oracle calls this read consistency. Once the system has determined the transaction was successful the COMMIT is complete and the new state of all records becomes visible to the rest of the system. This sort of mechanism makes a change appear instantaneously - in this case our database update and publishing the event.

Thus the events are published during the update, but the event receivers are called using tRFC, which is an asynchronous process. I may be wrong here but it is my understanding that this tRFC "becomes visible" in the RFC list and is processed upon successful completion of the LUW, i.e. after the instance at which the DB has been updated.

That's how a simple update task should work in theory, but in practice it gets more complicated. Not only do we have update tasks but we can also submit something in a background task or via RFC. They transaction such as the sales document would typically have a V1 and V2 update. Most likely the user exit will be processed during the V1 update, so raising an event will call the event receiver before the V2 update has started. Raising the event in a user exit using an update task and adding a COMMIT WORK statement will have the same effect because this will have it's own update task that is likely to execute before the transaction's V2 update. For this reason most user exits / BAdIs should not contain any commit statements, because this would cause the lightning/thunder effect you described - you would effectively break the transaction into two separate update tasks. The solution here is to raise the event in an update task but without any COMMIT statements - this would then be executed together with the transaction's own update task.

That's all theory, who knows what weird and wonderful coding SAP may have in place just to be different.

Cheers,

Mike

[Former Member]

Hi Mike,

I like the direction you're going but first let me thank Colm for letting us have this dialog. While we may not be answering his question directly, I believe this topic is a very important to anyone who works with SAP Workflow.

Mike, I'm with you on your explanation and essentially had the same understanding myself. Your point about the Event Receiver being run in tRFC is quite true and that it is not seen by the queue until the LUW that called it completes and commits (explicitly or implicitly). The RFC call actually just registers the FM and Parameters in the ARFCSTATE (and other ARFC...) tables, which in itself is just data. The registration data has to be committed before the queue sees it - again to your point about read consistency.

Back to BSVW. I'm aware of it, haven't used it, but I have implemented Change Documents for a "bolt-on" that stored complex approval rules for FIPP. The business wanted to know when and who changed a rule so CD's was the route I took capture that info.

Ultimately, I had to place the call to the Change Document Function Modules in the logically correct position of the Z-program (actually a Function Group).

Do we know if SAP's call to create the CD's for the Maintenance Order is positioned correctly within the SD code? Maybe that's what needs to be examined, which get's back to an earlier point of yours that this is becoming OSS note territory.

OR

Maybe we need to ask Colm if a COMMIT WORK is being issued in any of the SD User Exit Subroutines effectively breaking the LUW in the manner you just described above.

Regards,

Thomas Carruth

[Former Member]

Mike - I didn't answer your question to me, so let me try now.

Your earlier explanation is perfecty valid and is a common problem people have with workflow events. However I'm not sure why you say that another COMMIT WORK would be required? The effect of the COMMIT WORK is to submit all the queued updates as a single LUW which either succeeds or fails. Raising the event is part of the LUW, so it too is subject to a rollback if anything in the LUW fails.

I see it as the first COMMIT WORK submitting the updates to the Update Processor. Just that - a submission of work to do. The Update Processor is an entirely separate running process on the Application Server. I like to think of it as just another user on the system.

With the update registrations committed, only now does the Update Process see them and subsequently starts updating. (If it fails we see the failure in SM13). Now within the Update Process itself, I believe there has to be a COMMIT WORK (#2) that effectively commits the "INSERT ... INTO VBKP ..." and others.

Doesn't this get at the heart of the SAP LUW. The updates from COMMIT WORK #1, which in itself is a physical DB transaction plus the updates from COMMIT WORK #2, another physical DB transaction, constitutes the Logical Unit of Work.

That's why I believe two COMMIT WORK are needed - One at the end of the Dialog Process, and another at the end of the Update Process (it may be built into the Update Process that a COMMIT WORK [#2] is issued at the completion of all the updates - not sure).

Regards,

Thomas Carruth

Edited by: Thomas Carruth on Mar 31, 2009 9:00 PM

[pokrakam]

Hi Thomas,

Another great explanation, and agree it's useful for people to understand how this works.

>

> I see it as the first COMMIT WORK submitting the updates to the Update Processor.  Just that - a submission of work to do.  The Update Processor is an entirely separate running process on the Application Server.  I like to think of it as just another user on the system.
> 
> With the update registrations committed, only now does the Update Process see them and subsequently starts updating.  (If it fails we see the failure in SM13).  Now within the Update Process itself, I believe there has to be a COMMIT WORK (#2) that effectively commits the "INSERT ... INTO VBKP ..." and others.

I think you are either confusing CALL FUNCTION ... IN UPDATE TASK with CALL FUNCTION IN BACKGROUND TASK, or confusing SAP COMMIT's and database COMMITs (which aren't used in ABAP). Both are very different, and a second COMMIT WORK could be used in the case of background updates since they are called using RFC (effectively another user as per your explanation).

Update tasks are a lower level process and form part of the same LUW. V1 update happens in the same dialog session and V2 is a lower-prio update that is deferred but belongs to the same LUW. It is possible to crash a V2 update and end up reversing the V1 update. The system will send the user a mail when it happens - they will have e.g. gotten a message "Sales Order 9999999 has been created" and it then no longer exists.

The doco on this explains it very well:

[http://help.sap.com/saphelp_nw70ehp1/helpdata/en/e5/de86e135cd11d3acb00000e83539c3/frameset.htm]

Cheers,

Mike