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 All,

Yes Thomas you are correct, when we are testing in SWUE we are testing with an already created order so I can see your point about the timing issue.

However I don't think this should be the problem because we are passing a container into our start condition and it is the container that is being checked against. So even if the document hasn't been created in the system yet, surely this container should still have the values in it to validate against?

Or am I completely wrong?

[Former Member]

Hi Colm,

True, you are passing Container Elements, one of which appears to be a Business Object Reference.

The Start Condition upon receiving that reference first has to Instantiate the reference. To do that it has to read from the Order Table. But guess what - the data for that Order Key does not exist - yet.

The solution proposed above by Arghadip is a very good one and you might want to give it strong consideration. And yes, it may result in the creation of unnecessary workflow instances, but it should resolve your immediate issue.

In tandem, consider running SWWL to delete those irrelevant workflow instances.

Regards,

Thomas Carruth

Chief SAP Workflow Consultant

SBWP Service Corp

[Former Member]

Why wouldn't the data exist in the tables?

Because the SQL Inserts are called in an Update Function Module, which in turn is passed to, and performed by the Update Process, which is an entirely separate Application Server Process.

By the time the Update Process gets to start the update (very fast), the triggering event had already fired. Hence the Start Condition finds itself working with a logical reference that has yet to be physically created in the DB.

Here's the most important thing to understand.

When you save the Order, the corresponding COMMIT WORK does not write the actual order data to the tables. It writes data into system tables that registers the data needed by the Update Process to write the Order Data to the tables.

The Update Process reads the registered data, which is actually all the parameters needed by the Function Module that was called "IN UPDATE TASK" much earlier when you saved the order.

This all has to do with the SAP Logical Unit of Work (LUW) and the Update Process.

To add anymore on the subject is probably outside the general scope of this forum, though if you are going to be developing workflows on a regular basis, it makes for good bedtime reading to learn as much as you can about the the SAP LUW, Update Tasks, and additionally, the tRFC Queue.

Regards,

Thomas Carruth

Chief SAP Workflow Consultant

SBWP Service Corp.

[Former Member]

One last thought...

Think of this all as "Thunder and Lightening". Better yet, "Lightening and Thunder".

Lightening is the Event. Thunder is the Update.

You see the Flash of the Lightening before you hear the Sound of the Thunder.

Regards,

Thomas Carruth

Chief SAP Workflow Consultant

SBWP Service Corp