Down port of HR renewal 2.0 to HR Renewal 1.0

[S_Strangfeld]

Within my last blog Roadmap Forms and Dynamic Processing Rules - enhanced data quality and higher system automation with... I announced a down port of the HR renewal 2.0 functionality to EhP6 in November 2014, so that all customers who have implemented HR renewal 1.0 based on EhP6 can also get the great new functionality of e.g. Dynamic Processing Rules.

I am now happy to inform you that this downport has been available since November 13, 2014 with Support Package 31 (SP31) of HR renewal 1.0.

HR Renewal 2.0 FP1 and FP2 offer a wide range of new functionality for HR Professionals users. This functionality has also been downported to HR Renewal 1.0 SP31. The following enhancements are included:

• HR Professional: Dynamic Processing Rules
  • Offering Dynamic Processing Rules for the HR Professional solutions (in individual Infotype screens and HCM P&F Roadmap Forms
• HR Professional: Enhancements to the Roadmap Form:
  • Add attachments to roadmap form steps, Select from multiple valid infotype records in roadmap form operations, Use "Delete" Operation within HCM P&F Roadmap Forms configuration
• HR Professional: Enriched Context-Relevant Navigation
  • Configure navigation targets for Infotype UIs to give users more context-relevant information (other infotypes, reports, web applications)
• HR Professional: New Role Version and Launchpad Enhancements
  • Easier handling of country content in the Launchpad configuration
• HCM Processes & Forms Enhancements
  • After saving a draft, user can continue to edit form, utilities feature in Roadmap Forms, improved handling of Roadmap Forms in Processes Lane and HCM P&F Process Monitor
• HR Professional: HR Object Delimitation
  • For more information see SAP Note 1883014.
• HR Professional: Country-Specific Content for
  • Austria, Ireland, Malaysia, Russia, Singapore, and South Africa, Philippines
  • Germany: Private Sector and Public Sector

For more information and documentation links, see SAP Note 2071342 (http://service.sap.com/sap/support/notes/2071342).

Note: If you are on a support package (SP) lower than SP 31, and you require corrections to any objects that have been changed in this SP, you must
implement this SP to get the applicable corrections.

Detailed configuration information and screenshots for the new features are available in SAP Service Marketplace at http://service.sap.com/hcm > CoreHR and Payroll >  HR_Renewal > Resources > Implementation Information.

Note: You need to be a registered user to view content in SAP Service Marketplace: http://service.sap.com/login.

We will also have two Expert sessions for partners in January 2015

• Dynamic processing rules - New feature of Human Resources RENEWAL 2.0 on January, 13th 2015
• Enhancements for Human Resources Professional Solution Human Resources Renewal 2.0 Feature Pack 2 January, 14th 2015

To register please go to SAP Partner Edge https://partneredge.sap.com, and search for HR renewal.

HR Renewal 2.0 FP1 and FP2 offer new functionality and enhancements for ESS and MSS users too. This functionality has also been downported to HR Renewal 1.0 SP31. Here the following enhancements are included:

• HR Employee Self Service
  • More efficient ESS Timesheet based on SAPUI5
• HR Manager Self Service
  • Substitution short lane and expanded lane on SAPUI5 enables managers to flexibly substitute workflow based approvals, non-workflow based approvals, and applications to other users in the organization.
  • Re-designed Timesheet Approval based on SAPUI5
  • Archiving/destruction of notes in the Employee Profile

For more information and documentation links on ESS/MSS downport, see SAP Note 2063410 (http://service.sap.com/sap/support/notes/2063410).

You might also find these three blogs of my colleague Gertrud Beisel regarding the delivery of HR renewal 2.0 itself useful:

HR Renewal 2.0 Initial Shipment Released for General Availability

HR Renewal 2.0 FP1 Available

Feature Pack 2 Released for HR Renewal 2.0

Hope to welcome you in our sessions :wink:

And... as always... Looking forward to your feedback.  If you have any questions feel free to contact me.

Sylvia Strangfeld

sylvia.strangfeld@sap.com

[ChrisSolomon]

Thanks for the info! I saw that note go out just the other day. I was going to post a blog as well, but of course, more with an HCM P&F slant to it. You beat me to the punch! haha

I am glad to see more enhancements to "Road Map" forms and the new "dynamic processing rules", but also just wondering why SAP is putting much into them at all (personally, I do not care for either.). Have that many customers been clamoring for this? I don't really see much use (or "buzz") for them "out in the wild". It is almost quicker/easier just to configure your own process than to use "Road Map" forms and have to accept their MANY limitations. As for "dynamic processing rules" (ie. SAP's HCM P&F answer to "dynamic actions"), I just wish SAP would have let "dynamic actions" die off on their own rather than appearing to support them "in a fresh, new way". I understand there are customers with very complex dynamic actions they have held onto for many years, but it is better to ween them off of those in my opinion. Isn't SAP's new strategy to "run simple"? :razz:

[SimoneR]

Hi Christopher, you don't seem to be a fan of dynamic actions 🙂
Well, customers in many countries see legal requirements forcing them to make sure that infotypes related to each other are always changed together. This is what the Dynamic Processing Rules helps them with. In some functional areas, like Garnishments, it is only be linking up the infotypes with the means of DPRs that the entire solution gives lots of benefits to users. Maybe it's a country or industry specific interest that raises the need for the dynamic rules somehow. Dynamic Processing Rules is not really the "SAP's HCM P&F answer to "dynamic actions", but the solution for dyamically related employee master data changes in roadmap form as well as individual infotype changes (e.g. in the Master Data Application within role HR Professional). True, though, SAP wants to "run simple" and help customers "run simple" - so at least the config of the DPRs should be much simpler than the old dynamic actions 🙂 (we cannot prevent customers and consultants trying the most complex rules with own abap classes, though....)

[ChrisSolomon]

Simone, first off....thanks for the reply!!!! Very cool to chat with you!

It's not that I am not a "fan" of dynamic actions. I just think they are an old solution that had it's time and place, but we can certainly do better nowadays.

Why not use the decoupled/detached infotype framework classes for this purpose? Customers could make their "dynamic rules" within the classes to insure that where ever the infotype is "touched", their rules would be checked/applied. I thought that was part of the point of it all when that framework was released (ie.besides segmenting the UI layer from the logic layer... having complete input/output control to apply any additional business logic within that layer). Are there plans to have the "new" dynamic processing rules somehow integrated into that framework or are customers back to the same problem (ie. having to over-manage where all of their business logic/rules "lives" and likely having to duplicate them in several ways/places)?

[former_member34346]

Hi Christopher,

as your question addresses technical details, I will take over from Simone 😉

The decoupled infotype framework "only" addresses the business logic. It has no real "control" about the UI. In principle you are right: the decoupled infotype framework could be the place where dynamic rules are defined. However this could only cover rules with pure backend logic. For example rules that update another infotype with a predefined set of values would be possible. However, as soon the end user needs to be involved, for example to enter some field values of the dynamically added infotype, the decoupled infotype framework itself cannot fulfill this. It always needs the application to react and to present the corresponding infotype screens to the end user.
We thought about introducing an eventing mechanism into the decoupled infotype framework that informs the ("registered") application(s) about additional actions to be taken. However this is not really compatible with the transactional concept defined in the decoupled infotype framework. Furthermore there are additional layers on top of the decoupled infotype framework (UI conversion layer, BOL, FPM feeder classes) that would make this "eventing-channel" extremely difficult, if not impossible.

We therefore decided to define the dynamic rules on the level of the so called "Configuration-IDs". These configuration-IDs (currently) represent infotypes in the area of the HR Specialist role. But as the infotype number can be derived from the configuration-ID, there is - in principle - no limitation to the HR Specialist role but other roles like ESS for example could also be supported... However, up to know, I'm not aware of requirements to support dynamic rules in ESS-scenarios...

[ChrisSolomon]

Thanks Martin for jumping in. I appreciate the explanation and your time in responding.

However, I will say I feel more disheartened than ever now. When Decoupled Infotype Framework was announced, it was positioned as the "new" way to free us from dependence on UI. The buzz was that it would free us from the complexity of PA20/30/40 (as they have grown over time into a tangle of patches, user exits, country specific code and so forth that can be handled better in purpose-built classes loaded as needed) and make way for a "new", simpler, consistent, more efficient way of handling HR data (including getting rid of concepts past their prime like macros and dynamic actions). According to info that came out, SAP knew this would take time, but eventually, DIF would be the new backbone of all things HR/HCM for SAP core business suite. This would allow for any kind of UI for the customer with their confidence in having their business logic/rules handled accordingly (and hopefully in one, easy to maintain "location"). I would love it if some mechanism was built into DIF like a rules processing engine (SAP has plenty of rules engines lying around....look at other products and solutions haha) that would possibly do something as simple as throw an exception/event to make sure that "based on rule N, if infotype X exists than the UI of whatever kind must also provide fields 1,2, and 3 from infotype Y". But now, this just sounds like SAP went "yeh, we tried to decouple infotypes from the UI, but our think tank just couldn't come up with a way to do it....so we are just going to come up with a re-packaged, re-named version of Dynamic Actions and make it sound like the next greatest thing...besides, we gotta get back to focusing on SuccessFactors." :lol: OK, maybe that was a bit over-dramatized, but I hope you get my point....waiting for years for this supposed big replacement only to get pretty much the same thing under a different names is maybe just a little bit disappointing.

I will try to give Dynamic Processing Rules the benefit of the doubt until I have time to "play" with them some more. But having to think about going backwards to again having to keep up with business logic in these rules and in the DIF classes is not putting me into a happy place. :mad: And you have to know that you will now get questions from people (like me? haha) to when this is going to come to HCM Processes & Forms past just "Roadmap" forms. Many customers developed custom generic services to duplicate what their related dynamic actions were doing. So now they will of course wonder (1) will this be available as standard and thus make that kind of custom development no longer needed (2) if not, are you telling me that I go back to having to maintain business rules/logic in multiple places (now it would be in DIF classes, in dynamic processing rules AND in HCM P&F services because they can't read/handle dynamic processing rules....and lets not even mention their many user exits and other BAdIs in place until they get off of those too)?

Again, not trying to be a "downer", but trying to better understand why SAP went this route. Apologies to sylvia.strangfeld for slightly derailing the original blog post, but this is some lively discussion (and near-and-dear to my heart as well) with SAP product managers that we don't often get enough around here at SCN.

[Former Member]

First off, let me say that the DPR is a very elegant solution!  I was very pleased with how easy it was to launch other infotypes from within both roadmap forms and dynamic actions.  Well done!

However, I am going to have to agree with Chris's main theme: DPR does seem to get us back into the same rut as before of having business logic tied to a specific UI.  SAP HR is the most widely installed HR package in the world.  I'm really excited to go to the install base and extol the virtues of the new HR Professional Role (which I think is a huge improvement over the classical UI!).  However, it's going to be a difficult conversation to be had around how to handle their HR business logic.  Here are there options as I see:

1. Rebuild the old dynamic actions as dynamic processing rules (DPR) and abandon the old dynamic actions.  This would effectively mean sun-setting use of PA30/PA40 which is going to be a tough sell.
2. Rebuild the old dynamic actions as DPR and retain as well on the dynamic actions.  In this approach the customer will have dual maintenance.  Also a tough sell. 

You can double the complexity for either option if you also use HCMPF since the business logic will also need to be stored in a decoupled infotype BADI.  So if a customer used PA40, roadmap forms, and HCMPF the same business logic might need to be stored 3 different ways in 3 different locations.

I think that most customers would prefer that we have one spot--be it dynamic processing rules or the decoupled infotype framework where they can store their business logic and have it fire regardless of which UI the user is currently in: PA30, HCMPF, Roadmap Forms, or ESS.  While I get the point about the UI control, I just wish that it was possible that all customers that wanted a single solution and were willing to deal with the UI limitation that there would be a way they could put all of their logic in DIF and be done with it. 

This is not to say that SAP won't change how it works.  I've been really pleased the amount of innovation coming out of SAP HCM on premise in the past 2-3 years.  It's great that we are having this conversation because it means that SAP has developed something new and compelling that customers will want to adopt.  I wouldn't be surprised to see the SAP folks come out with a solution that unifies the business logic.  Keep your fingers crossed Chris!

[ChrisSolomon]

Thanks Brandon! I think you "get" what I was trying to say. Like I said, I didn't just come up with this out of thin air nor is it my own crusade against dynamic actions.(I bet we would have some cool looking shields! haha) I have heard this from others as well over the years. Like you said, hopefully SAP will come up with a solution that unifies/centralizes custom business logic....but I am not sure I can cross my fingers quite that long....I do have to do work, ya know. haha :razz:

[former_member34346]

Hi Christopher,

the decoupled infotype framework is and remains the central backbone of handling HR-data.
If you like, you can also interpret the Dynamic Processing Rules customizing tables as being part of this infotype framework. As I said, there is a relationship between infotypes and configuration IDs used in Dynamic Processing Rules.

And, as I said, Dynamic Rules that request the user to provide some more input always have a UI relation. The application has to react on that and provide the relevant UI. Whether the application reacts on events being triggered by the infotype framework, or reacts on the information given by the dynamic processing rules engine (we have developed an API that principally could be used by any application) makes no difference.

You would like to have the dynamic processing rules being integrated into the HCMPF framework and expecially into Adobe PDF forms? I would really be interessted in how you propose to handle the UI-part... Generate additional PDFs to pop up containing those fields being relevant to the dynamic processing rules? Or can you manage to generate them on the fly into the existing PDF? I doubt... And: generated screens normally/always look ugly... You cannot optimze them using approriate UI-controls like dropdown lists, checkboxes, radiobuttons, etc.
As you see: dynamic rules have a strong UI relationship.
That's also the reason, why dynamic processing rules (like dynamic actions) refer to complete infotypes rather than individual fields (e.g. "create infotype X" instead of "provide fields A and B of infotype Y"). The latter one would require lots of additional UIs for all possible combinations of fields - and UI-technologies (WebDynpro, PDF etc.).

I dont's see things as dramatical as you describe them. We get very good customer feedback for the dynamic processing rules. I'm not aware of customer feedback requesting to provide dynamic actions in ESS-scenarios or MSS-scnearios... However I'm aware of customers requesting dynamic actions in HCMPF-(PDF)-forms. But - as described above - this would be hard to realize.

[former_member34346]

Hi Brandon,

also see my comments above in my answer to Christopher.

Regarding double maintenance of dynamic actions and dynamic processing rules:
I agree, this is not optimal... Unfortunately it's the same as for most other aspects related to old infotype framework and decoupled infotype framework: the decoupled infotype framework is not able to deal with the customizing/settings/BAdIs of the old framework. There was no option to reuse the old dynamic actions customizing. Vice versa it is also no option to reuse the new dynamic processing rules in the old PA30/PA40 transactions.

However to support the customer, we will provide a conversion tool. This will transfers dynamic actions into dynamic processing rules. This will work pretty well for the pure customizing part, but - of course - manual work is needed, if customers implemented additional form routines.

[ChrisSolomon]

Martin....again thanks for the response. My reply...do not think in terms of PDF (AIF) UI....think more abstract....but if you like, we could think in terms of FPM forms (which are available) and the underlying WDA code. Generating controls and bindings for UI elements/fields in WDA "on the fly"/dynamically is easy. I would think that in some similar manner, the feeder class (or some other like the HCM P&F framework) could "execute" those Dynamic Processing Rules(DPR) and generate the needed UI "on the fly". Now, as you said, this generated UI might be ugly so even then I could see where a "designer" could layout the page/screen and the "whatever" option could then trigger/set which fields are available (ie. UI attributes) based on the DPR. Something along those lines.

Also, it would be nice to disassociate DPR from complete "actions" and make them more generic/open. If we are going to have a "rule engine", then it might be nice to make it usuable, as you question, in ESS/MSS scenarios. For example, in an ESS situation, I could set up DPR so that for example if an employee changes their address, there might be additional "rules" that also ask bank, emergency  contact and/or tax related information. This would not be a "traditional" action (ie. hiring) but could work similarly and at the same time, a "traditional" action would still work into this nicely. A lot of times, I see custom (and/or "country specific") solutions having to be built for something that simple. I guess without getting into it and more experience with DPR, my question is more "Can we built rules against an infotype change vs against/for a particular action? And then, can we use those 'rules' in multiple places (like reusable code)?"

I don't know....maybe my coffee has not fully kicked in...but as you can well tell, I do not adore old "dynamic actions" and do not wish/want/need just an updated version of them re-wrapped, re-named, and re-coded if it really does not buy me much. I think *if* some similar/same mechanism is still needed, why not take the opportunity to make it MUCH better and usable? As brandon.toombs3keyed on, it would be nice from a customer perspective if we need only maintain custom business logic in a centralized manner. Maybe the way we do this is not "centralized" but perhaps a nice transaction could be created (a "cockpit" of sorts) to visibly show us the locations (and info types affected) of all customizations (and please don't say "Solution Manager" haha)?

[former_member34346]

Hi Christopher,

thinking abstract is a good thing! But when it comes to implementation, you also have to think concrete.
I choosed PDF as the example, because it makes the strong UI-relationship abvious. What's next? SAPUI5? Then it gets even worse because you have to think about (generated/generic?) ODATA-services.
You want to restrict dynamic rules to WebDynpro ABAP? OK. This can be done. We both agree that generated screens might be ugly. So you have to provide the possibility for a designer to create/design the screens. That's what we did. We currently restrict it to "whole" infotype screens, as we know how to handle them (they are represented by a screen structure and are "managed" by a feeder class). But even right now, these "whole" infotype screens can be stripped down to only include some of the fields...  Superfluous fields can be removed. The ugly thing is, that you again end up in a huge set of screen definitions containing various field combinations.

The other thing is the assembly/layout of those screens in the UI. We decided to use the roadmap approach (individual steps on the left hand side, details screens on the right hand side) because we assume customers will normally reuse our (fullblown) infotype screens in dynamic actions rather than creating new/dedicated/small screens. So customers have the recognition (same look and feel) like in the roadmap forms (predefined sequence and dynamic sequence). An alternative assembly/layout of the infotype screens would be to place them all on one screen next to each other in a sequence. This would be more suitable when the screens are small. This is definitely an option which could be realized in the future.

Yes, the rule engine API is created in a way that ESS/MSS could use it as well. It just means, that the ESS-/MSS-applications which should support dynamic actions need to be extended. If customers request this functionality, it could be implemented.