Custom Business object getting called without Delegation

[former_member206593]

Hello,

I have an existing Workflow getting called upon CREATE/CHANGE events of BUS2032(Sales order). Now I have an another requirement to call another Workflow for Sales Orders but based on certain conditions(which can not be handled in SWEC condition Editor). The conditions for new Workflow are not valid for the old one. Neither can I check those conditions within the same old Workflow.

So, I thought of creating ZBUS2032 having subtype as BUS2032 with NO Delegation and trigger the CREATED/CHANGED for this ZBUS2032 from within the Code based on my conditions.

SWEC:

1. I have not maintained any entry in SWEC for this new Z object.

2. No entries have been maintained even for BUS2032 as standard code triggers the CREATED/CHANGED events.

SWETYPV:

1. An entry exists for BUS2032.CHANGED to trigger the old Workflow.

2. I have only maintained 2 entries to handle my new Workflow upon trigger of these ZBUS2032.CREATE/CHANGE events.

The issue is, when ZBUS2032.CHANGED is triggered from within my code, the Old Workflow is also getting triggered along with mine, so it is getting triggered twice - once with BUS2032.CHANGED and 2nd time with ZBUS2032.CHANGED. I have checked everywhere, the Old Workflow is not getting triggered from any custom FM/program/User Exit.

I know, I can put a Check FM to stop the old Workflow from getting triggered if event is ZBUS2032.CHANGED. I can also create a new event in ZBUS2032 instead of CHANGED and trigger it, but I want to understand how ZBUS2032.CHANGED is triggering other workflow without any Delegation and any entry in SWE2.

Thanks in Advance.

[Former Member · Accepted solution]

Hi Saras

an event of the subtype "truck" will also process the event-linkages for all super-types, e.g. "car" in the hierarchy.

Florin

[former_member206593 · Accepted solution]

Thanks Florin. I guess that is what was happening.

[former_member185167]

Hello,

"So, I thought of creating ZBUS2032 having subtype as BUS2032 with NO Delegation "

How did you do that?

I thought the only options were to subtype and delegate, or make a completely new copy.

Maybe you should consider making a copy, though I would only do that if I had to, e.g. if the new object has different keys.

regards

Rick Bakker

[Pyc]

G'Day,

It is definitely possible for an object to have multiple subtypes. A super type of a 'vehicle' can have subtypes of 'car' and 'truck'. This means that if the super type is enhanced to have some new attribute (maybe 'fuel efficiency') then all subtypes will benefit. However an object can only delegate to one subtype. If you say a 'vehicle' should delegate to 'car' then all reference to 'vehicle' will produce 'car' behaviour.

In terms of events, raising an event of a supertype at the subtype will raise the same event at the super type level. If you don't want this to happen you need to define subtype specific events and raise these.

In the scenario described CREATED is raised as standard and then you've configured to raise it again, hence to instances of the original WF.

In this particular case I'm not sure there is justification for another subtype. What is the logic that you believe can't be handled in a Start Condition or Check FM??  You can create a new virtual attribute with as complex logic as you require and use it in your checks. If the logic is really too inefficient to include in an attribute then create a Check FM.

If you really think a new SWEC based raise is needed, then raise a specific subtype defined event.

Have fun,

Mark

[former_member206593]

Thanks Rick and Marc.

The logic is I need to trigger the new Workflow upon Change of certain standard fields which do not have Change Document enabled and I can't see them in SWEC. I can't even catch them in Check FM as the DB is already updated with the new values, by then.

As you said: "raising an event of a supertype at the subtype will raise the same event at the super type level.". The issue is a little different. It is not raising the same event for Supertype again but triggering the Original WF again on raising the event for Subtype, when only configured for Supertype.

This is what I can see in SWEL:

BUS2032     CHANGED       WF1 - Triggered by Standard

ZBUS2032   CHANGED       WF2 - Triggered by Me

ZBUS2032   CHANGED       WF1 - Triggered again

I think, I will have to create new Event for subtype.

[Pyc]

Hmmm, I'm pretty certain that is more an issue with the way SWEL is recoding what is happening. As you've said WF1 is only interested in BUS2032, it will be the supertype event invocation which is occurring.

If you need to know about old and new values which don't have Change Docs enabled you've got a couple of choices.

You could switch on Change Doc recording for the associated Data Elements. This is a repair, and needs some consideration, but is certainly not that unusual to do. The treat is that it's that simple most of the time. Switch on the flag at the Data Element and the Change Doc entries will be successfully generated.

You may have an appropriate BAdI available to you where you can compare old and new value and raise a custom event (use the WAPIs and make sure it happens in the update task).

Given that it is a specific fields or fields you're interested in, I'd definitely go with a new event name. CHANGED is generic. You are dealing with a specific scenario.

Have fun,

Mark

[former_member206593]

• "it will be the supertype event invocation which is occurring."

Yes, that explains it all.

• "You may have an appropriate BAdI available to you where you can compare old and new value and raise a custom event (use the WAPIs and make sure it happens in the update task).       Given that it is a specific fields or fields you're interested in, I'd definitely go with a new event name. CHANGED is generic. You are dealing with a specific scenario."

Perfect!! That's exactly what I have done. I used an Implicit Enhancement to trigger WAPI in update task. I finally created a new Event, as you suggested.

Thanks a lot Marc.