HCM P&F: Why are scenario 1 services being called in scenario 2?

[bryan_cain]

The title pretty much says it all.

A field that I am populating via a service in scenario 1 is not being passed to scenario 2. Before I started looking at the scenario 2 form, etc, I stuck a break point in the service and started from scratch. The code worked as I expected it to.

I submitted the form,opened my UWL, clicked the new task, and it hit my break point again. In fact, both of my custom services for scenario 1 are being called from scenario 2, even though there are NO custom services defined for scenario 2.

Why is that? Did we configure something wrong, or is this another one of SAP's undocumented 'features?'

Thanks in advance as always...

Bryan

[ChrisSolomon · Accepted solution]

(1) Are you sure you are passing fields from scenario to scenario (ie, the bottom part of the left side "config tree" of the Design Time workbench)

(2) Are you sure your workflow is actually set (via bindings) to use scenario 2 on the task step you expect it to be doing? I would imagine it is not and that's why you are seeing scenario 1.

(3) Just to make sure I ask, are you sure you mean SCENARIO and not FORM STEP? If you are actually talking about 2 form steps in the same scenario, then yes, alll backend services within the same scenario will apply (unless you use "rules" to control them). But I am pretty sure from reading your post, that this is not the case....just had to ask....people trip up on the "lingo" of HCM P&F a lot.

Let's get this worked out for you!

[bryan_cain · Accepted solution]

1) It looks like that field is on the list. Names correct, etc.

2) I'll follow up with the workflow guy, thanks.

3) Yes, I meant scenario. This has been set up such that each scenario as a single step. I actually caught myself and rewrote the original post, because I had written step and not scenario.

Thanks!

[bryan_cain · Accepted solution]

On 2:

Just realized - each scenario has a different form. I'm definitely seeing the scenario 2 form when I load the work item from the UWL. I don't have an answer from our WF guy yet though.

[bryan_cain · Accepted solution]

OK, it looks like it yes, the form is bound correctly.

&FORM_SCENARIO_STAGE& is ZHCM_PC_02_A

and

&FORM.FORM_SCENARIO& is ZHCM_PC_02

Both of those values are correct.

[bryan_cain · Accepted solution]

On the missing field issue:

I think the reason the field is being dropped is because the service is being called twice. The first time it is being called with only the "required" fields (pernr, edate, massn, massg) and the second time it is being called with all 5 fields. The other services is also being called twice, but it has all 77 relevant fields both times.

Any ideas why 1 service is being called with 1 field missing?

[ChrisSolomon]

Can you kind of "chart out" your config? It would help....like...

process--
+ form scenario 1
     ---form step A
     ==backend services
         *service 1
         *service 2
+ form scenario 2
     ---form step A
     ==backend services

[bryan_cain]

Sure, it looks like this:

Process: ZHCM_OCPC
---Form Scenario 1 ZHCM_PC_01[0]
-----Form Step (only 1) ZHCM_PC_01_A
--------Service 1 SAP_PA
--------Service 2 Z_ACTION_REASON "populates a dropdown on action reason, based on massn.  
                                 "then updates a non-screen field with the selected text, 
                                 "so we don't have to  write code in scenario 2.  
                                 "Incidentally, this is the  field that is being lost
--------Service 3 Z_COMP_RATIO  "calculates base comp ratio in initialize, and
                                 " new comp  ratio after the  user presses a button. 
                                 "  populates drop downs for  wage types. also
                                 "  copies text back to pass to scenario 2
---Form Scenario 2 ZHCM_PC_02[0]
-----Form Step (only 1) ZHCM_PC_02_A
---Form Scenario 3 ZHCM_PC_03[0]
-----Form Step (only 1) ZHCM_PC_03_A
--------Service 1 SAP PA

Does that help?

[ChrisSolomon]

So wait a second....first issue...you say

 "calculates base comp ratio in initialize, and
           " new comp  ratio after the  user presses a button. 
           "  populates drop downs for  wage types. also
            "  copies text back to pass to scenario 2

So this implies a "User Event"...right? So then, if this is a user event, are you making sure that you have all the fields needed in your "field group" of the User Event (ie. one should be that field from the previous service that you say "disappears". I am guessing it is NOT in the User Event field group and that's why it is clearing. Now if that is so, your question will likely be "but why should it be in there? it's not part of the service I am using for my User Event?" I will just say, please read my blog about "gotchas" on the User Event section as well as other posts I have made in this forum about the "wonky" way that is handled. Sooooo can you check that for me first?

Second, did you check the workflow task binding and make sure it is set to Scenario 2 form step 1 version 0000 and not to Scenario 1?

[bryan_cain]

Issue 1:

Yeah, it's a user event, and I've checked, all the fields necessary are tied to the user event. The user event has the same name as the operation, and the field groups have the same names as well.

Issue 2:

It definitely loads the second scenario. The second form is slightly different than the first form. It's just that before it loads the second scenario, it runs the services from the first scenario. So far this hasn't really been an issue - the services are coded such that you can run them as much as you want, and unless the values change, the result is the same. That said, it's weird.

[bryan_cain]

Well, I fixed the first problem. There were 2 user events. one for the first service, and one for the second. I had to have the field in question (MASSG_TEXT) in BOTH field groups for the user events. Now it works fine.

That doesn't make much sense to me... but at least it works.

[ChrisSolomon]

Issue 1:
Yeah, it's a user event, and I've checked, all the fields necessary are tied to the user event. The user event has the same name as the operation, and the field groups have the same names as well. 

To be more clear on this...(a) the operation name in the User Event does not mean jacksh$t nor does it's field group name. They do NOT have to match the Backend Services field group names and operations (I know....confusing). All that user event "operation" name does is tie to a button on the form to pass the "operation" back. Then the HCMP&F framework looks in config and says "where is this user event?....oh, there it is....now what field groups does it have and what fields are bundled up in those groups?....got em...now for those fields in each field groups, what do I have to do with them? ahh....a check or initialize".....and then it's going to go to EVERY backend service that those field are part of to do the check/initialize...keeping in mind some fields are used in many backend services....so, yeh, you do NOT get to pick and chose and say "just do this one operation in this one backend service for this user event" (b) You DO have to make sure that any and all fields needed by your backend services are IN the user event's field group. This also has it's own bugs (detailed in my other posts). One of them being ANY service that uses (like in your case) MASSN/MASSG will also need all other fields that it requires. So for instance, say your user event is needed to "fire" your backend service #3 "check", it will also actually be firing all others using the same fields as well whether you like it or not. Also, even though, like I said, you only want service #3 to "fire", you will have to include fields in the User Event's field group that are needed in say service #1 (SAP_PA?) and service #2. So in your case, say, your service #2 takes MASSN and MASSG and this other field that is gettng blanked MYFIELD, then in your user event that maybe fires service #3, you STILL must include MASSN, MASSG and MYFIELD in that field group.

Does this help clear it up some?

Now as to why you are "firing" scenario #1 config while in scenrario#2, that's something else we need to look at.

[bryan_cain]

it will also actually be firing all others using the same fields as well whether you like it or not.

I think this is the part that I was missing, and it sort of explains why what I did to fix it worked.

You're right, this thing is a mess...

[bryan_cain]

OK, Scenario 1 vs Scenario 2:

I did have our WF guy check the config - here is my previous post on the matter.

OK, it looks like it yes, the form is bound correctly.
&FORM_SCENARIO_STAGE& is ZHCM_PC_02_A
and
&FORM.FORM_SCENARIO& is ZHCM_PC_02
Both of those values are correct.

As I said, it definitely loads Scenario 2 - it's just that before it does (and it's only right before the form displays in the browser) it fires the Scen 1 services.

I don't think it's a problem, but it is strange, and I didn't see it mentioned anywhere, which is why I posted about it.

[ChrisSolomon]

haha Yeh....don't get me started on User Events again...I can rant on and on and on (and did in my blogs and several posts here! haha)

Sadly....they have not changed how these User Events work...not even in EhP4. I think the whole thing needs an overhaul...with a LOT of customer/consultant feedback! 😃

As for your strange worflow issue, still thinking on this one. Something is definately not right. Once you pull up that wf task for scenario2-step1, you should be seeing ONLY that form scenario and it's services being triggered.

Oh btw....your naming convention on scenarios/steps/etc looks awfully familiar....like EXACTLY like a naming convention I created and documented for my last client. I wonder if some guys from there are working with you now. hehe

Oh! And based on that naming....for each scenrio, are you using a DIFFERENT form and ISR or trying to use the same form in all the scenarios (I am guessing your ISR might be ZHCM and form Z_ISR_HRASR_ZHCM if my previous guess about your naming convention is right. hahaha)

[bryan_cain]

I wonder who that might be....

[Former Member]

You guessed it Chris. It's me. I guess this is the only way to get in touch with you now, since you don't return emails! haha. Thanks for helping Bryan out with that. We're just about to test our 1st process from end to end. Heard through the grapevine you are in Atlanta again.

[bryan_cain]

Yes, we are using a different form and ISR for each scenario. And you're close on the names, but not quite.

[ChrisSolomon]

hahahahaha I KNEW IT! Too funny.

So yeh, my concern was you were trying to use the same form/ISR through all scenarios. That is a recent "feature" and I don't believe it would work quite well (hey, with this stuff, I don't buy it till I see it work! haha)

Sooooooooooooo....still wondering why Scenraio 2 thinks it needs to use/call Scenario 1 backend services. How about this....just for "grins and giggle" change your process start config info to start with Form Scenario 2, form step 2a, version 0. Then let me know what THAT tries to do on initialization of the form via the Start Application. I still have hunch something is wrong/bent/borked in the WF piece, so maybe this will help identify it (for instance, I could see a type-o saying used form scenario 1 but form scenario 2 form step 1...that would possibly confuse it to show the form for scenario 2 but run through scenario 1 config.....I know you should how the params are being set but the binding might be getting overridden elsewhere.