HCM Processes & Forms: The Many Faces and Frustrations of the Start Application
After working in the SAP arena since 1996 or so, I should really know by now to never assume anything with SAP products. My “common sense” is not always SAP’s developers’ common sense. My most recent case in point….the HCM Processes and Forms “Start Application”. Personally, I would think “sure, the application should be able to run standalone and provide alternate views for the HR Admin, manager and employee all within that one nice little application”. What I have found, however, is a tangled mess of dependencies and technologies that seems to suggest the developers thought “ok, this is how it will work….and why would anyone ever need to run it any other way (such as outside/without the portal or Homepage Framework)?”. And here, my friends, is where the story really begins…
The confusion here really stems from what we have seen in the past from SAP’s evolution. HCM Process and Forms, like other ESS/MSS applications, got a bit hung up in transition. The Start Application originally began as a WebDynpro Java application. However, this was ported over to a WebDynpro ABAP application with an update to the HR Admin functionality via enhancement packs. This did not include an update for the existing MSS and ESS portions of HCM P&F however (for some odd reason). Therefore, we are stuck in this bit of “transition” depending on how and who is accessing the Start Application. This is the “confusion” and frustration I will attempt to clear up in this blog. (note: I have seen/heard mention of the ESS/MSS ports to WDA coming soon in enhancement packs, but nothing official on that timeline)
The Many Faces of the Start Application
Regardless of who initiates a process, all users execute the same underlying application known as the “Start Application” (kinda makes sense eh? Start a process? The “Start” application? I know….not the best name, but hey, I didn’t make it up). However, how the user gets to that application and how the application behaves is triggered by a variety of parameters than can be passed to it upon launching. For example, this allows you to have to application skip employee selection and jump right to process selection (for instance, in recruiting and wanting to create a new position, an employee will not be known or used so no need to select one). As another example, you may know the employee as well as the process and want to jump right to the form view (for example, an employee might want to file a change of address). Again, this is all possible by utilizing parameters passed to the start application.
Before we go any further and again to be very clear, right now we are talking about the “true” Start Application (why I say “true” will become clear when we discuss the nifty little bait-and-switch SAP pulls under the hood for managers and employees scenarios). When we speak of the Start Application, we are talking about the WebDynpro ABAP application ASR_PROCESS_EXECUTE. It can be found by going to transaction SE80 and locating the “webdynpro component” called HRASR00_PROCESS_EXECUTE. The actual application name is ASR_PROCESS_EXECUTE as shown:
By double-clicking on the application ASR_PROCESS_EXECUTE, we can view the possible input parameters:
(*Side Note: If you want to disable the feature of automatic resizing of adobe form, you can do so by setting the application parameter DISABLE_ADOBE_RESIZING=X (set to false by default). Though the application parameter DISABLE_ADOBE_RESIZING of WebDynpro application ASR_PROCESS_EXECUTE (of WebDynpro component HRASR00_PROCESS_EXECUTE) is set to ” (false), if the user parameter OFF_ADB_RESIZE is set to X, then automatic adobe resizing will not work, but the adobe form will be displayed. See OSS Note 1273246.)
Start Application Variations and Views
The following are the possible end user views of the Start Application:
Which view the user sees, as well as what information on that view is shown is controlled through a combination of HCM Processes and Forms configuration and the Start Application WebDynpro parameters. Typically, we have the following 3 end user views and interaction:
HR Administrator – the administrator is presented with the employee search view initially to search and select from a broad range of employees. Upon selecting an employee, they will then select a process, edit the respective form and start the process.0.1.
*Manager – the manager is presented with a table of their directly reporting employees as well as possible options for other views (controlled by typical OADP MSS configuration). This differs from the HR Admin view which allows a free, open search of employees. However, like the HR Admin, the manager selects an employee, selects a process, edits the form and continues on with starting the process.</li><li>Employee* – in this case the employee is already known and we will also know which process they wish to start, therefore this jumps the employee directly into editing their form to start the process.
From the end user perspective, this all seems like a very fluid transition through the Start Application. However, under the hood, there is quite a bit more going on than they realize.
HR Administrator (the Employee Search view)
This is the easiest of the 3 end user scenarios to describe. The HR Administrator view will display a simple and enhanced search for employees. This allows the admin to locate any employee (limiting this “hit list” is possible via security and config settings).</p><p>!https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_04.jpg|height=167|alt=|width=313|src=https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_04.jpg|border=0!</p><p> </p><p>It’s also possible to jump directly into processes that do not require an employee to be selected up front (possible based on backend configuration as of EhP2 and possible based on the user’s frontend decision as of EhP4 for some processes). I covered this in a previous blog HERE (HCM Processes & Forms: Start Object?…we don’t need no stinkin start object!) .</p><p> </p><p>Looking on the portal side at the iViews for the HR Administrator business package, you will see two “Start Process” object. These are:</p><p> 1. com.sap.pct.erp.hradmin.11.start_processes</p><p> 2. com.sap.pct.erp.hradmin.11.start_processes_ee</p><p>These are simply iViews that call the WebDynpro ABAP “app integrator”. This app integrator simply executes the name of the WDA app passed as the “Application Name” setting as well as the additional “Application Parameters” values and any other that are being passed to it indirectly as well (ie, in the query string). These appear as:</p><p> </p><p>com.sap.pct.erp.hradmin.11.start_processes</p><p>!https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_05.jpg|height=302|alt=|width=300|src=https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_05.jpg|border=0!</p><p> </p><p>com.sap.pct.erp.hradmin.11.start_processes_ee</p><p>!https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_06.jpg|height=307|alt=|width=313|src=https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_06.jpg|border=0!</p><p>You will notice the difference between the two is the Application Parameters setting. The application parameter GET_PERNR=X tells the portal to retrieve the employee’s personnel number from the temporary storage and transfer it to the iView (ie. via Eventing which is discussed further down).</p><p> </p><p>And that’s about it. No real magic here. Basically, we have an iView that executes the WDA directly. Viola. </p><p> </p><p>(note:* there are ways to “split” functionality if you had various HR admins…like Time Admin, Master Data Admin, etc. or even something like US HR Admin, EU HR Admin, etc….by making use of the “initiator role” application parameter. I am covering the initiator role in detail in another blog.)
Now, if you think about it, there is nothing stopping us from just launching the WDA directly (ie. even without the portal) should we need to do this. As I said…this is the easy one…now things get much more complicated. Thanks, SAP. (haha)
Manager (the Controlled Employee Selection view)
Unlike the HR Administrators free-for-all employee search, the manager will see a selection of direct and indirect reporting employees based on their organizational assignment.
Manager employee selection view showing direct reports
(if no employees available)</p><p>!https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_08.jpg|height=165|alt=|width=361|src=https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_08.jpg|border=0!</p><p> </p><p>**** THIS IS WHERE THINGS GET CONFUSING!!!! ****</p><p> </p><p>The manager view is a bit “tricky”. It is actually a mix of technology and a 2-step-handoff of sorts. We actually use the “older” WDJ application to allow the manager to select from their direct/indirect reports. This value is then stored in shared memory by the portal. Then, the WDJ application hands off and calls the WDA Start Process application using the application parameter GET_PERNR (discussed later) which allows the WDA application to grab the selected employee, bypass the “employee search” view and go straight to the Process Selection view. To the user, they never notice the handoff.</p><p> </p><p>Did you get all that? No? Yes? Basically, we have a big “wrapper” that first calls a WDJ application to handle the employee selection view, and then it hands off the selected employee to our actual WDA Start Application. This is due to a limitation better described here:</p><p> </p><p>(From SAP documentation HRAS_ESSMSS_iViews_EhP2.pdf describing this eventing mechanism as it relates to the HCM P&F DPF but it relates to our case in the same way)</p><p> </p><p>On the Employee Information Page the manager can select an employee from the EE Search iView (Object and Data Provider). All other iViews react on the selection and display data of the selected employee. Technically the personnel number is transferred from the search iView to the other iViews on the portal page, also to the related activity iView. This mechanism is called Eventing. The applications, started via the related activity iView, are launched with the personnel number as parameter. With other words the application, e.g. Address Change, can be directly started for the employee selected from the EE Search iView. The Employee Information page is based on Web Dynpro for Java whereas HCM Processes and Forms is based on Web Dynpro ABAP. Due to the different technologies the transfer of the personnel number from a Web Dynpro Java (Related Activity) to a Web Dynpro ABAP iView (e.g. Digital Personnel File) is realized in</p><p>a two step approach: By clicking on the link for e.g. the digital personnel file a portal page with a launcher iView is called. The launcher iView calls another iView with which the Web Dynpro ABAP application can be displayed. As result the Personnel Digital File for the appropriate employee is displayed. The eventing and the transfer of the personnel number only works FPM (Floor Plan Manager) internally -from Web Dynpro Java to Web Dynpro Java iView. The two step approach allows to first transfer the pers number to the launcher iView. The pers number is then saved in the backend system (shared memory),where the Web Dynpro ABAP application can take it.</p><p> </p><p>Think of our Manager scenario as a “wrapper” that actually calls the WDJ for employee selection first, stores the selected employee PERNR in memory, closes the WDJ, then executes the “true” WDA Start Application which pulls the selected PERNR from memory.</p><p>!https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_09.jpg|height=269|alt=|width=567|src=https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_09.jpg|border=0!</p><p>Therefore, our “wrapper” for the Manager scenario will actually execute the 2 iViews (you can find these in the MSS business package in your portal content).</p><p> </p><p>These two iViews are:</p><ul><li>1. Start Processes (com.sap.pct.erp.mss.eeselection) : WDJ iView</li><li>2. HRAS Process (com.sap.pct.erp.mss.hras_process) : WDA iView</li></ul><p> </p><p>On the WDJ iView, we can set various parameters to affect the Organizational views used (via MSS OADP configuration). This determines what the manager sees as their direct and indirect reports in the organization.</p><p> </p><p>Once an employee selected, as mentioned, the handoff is made to the WDA iView. It’s settings are:</p><p>!https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_10.jpg|height=369|alt=|width=373|src=https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_10.jpg|border=0!</p><p> </p><p>In the standard system if the TEAMVIEWER_USED=X application parameter is defined for the iView, this tells the WDA version that it is being used in combination with the older WDJ version. The parameter specifies that the HRAS Process WebDynpro ABAP iView is accessed from the Start Processes WebDynpro Java iView from MSS, and that navigating back via the roadmap must return to the WebDynpro Java iView.</p><p> </p><p>The handoff between these two is handled by the “launcher” iView which is:</p><p> </p><p>In Homepage Configuration, this is referenced in resource key MSS_HCM_SERV_RELACTIVITY_START_PROCESSES which has the simple setting,</p><p>!https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_11.jpg|height=203|alt=|width=385|src=https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_11.jpg|border=0!</p><p> </p><p> </p><p>And PCD location:</p><p> </p><p>ROLES://portal_content/com.sap.pct/line_manager/com.sap.pct.erp.mss.bp_folder/com.sap.pct.erp.mss.pa</p><p>ges/com.sap.pct.erp.mss.hcm/com.sap.pct.erp.mss.relatedactivitieslauncher_startproc_page</p><p> </p><p>As you can see, the window setting “_blank” is what forces this to launch into a new window. The iView is title “Related Activities Launcher (Start Processes)” and has the parameter “Service ID” which has the value “MSS_HCM_HRAS_START_PROCESSES”. Looking up that resource key, we see:</p><p>!https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_12.jpg|height=178|alt=|width=361|src=https://weblogs.sdn.sap.com/weblogs/images/6987/startapp_12.jpg|border=0!</p><p> </p><p> </p><p>And the PCD location:</p><p> </p><p>ROLES://portal_content/com.sap.pct/specialist/com.sap.pct.erp.hradmin.bp_folder/com.sap.pct.erp.hradmin.1</p><p>1.bp_folder/com.sap.pct.erp.hradmin.11.pages/com.sap.pct.erp.hradmin.11.start_processes_ee</p><p> </p><p>Note:* if this PCD path is pcd:portal_content/com.sap.pct/line_manager/com.sap.pct.erp.mss.bp_folder/co
m.sap.pct.erp.mss.iviews/com.sap.pct.erp.mss.hcm/*com.sap.pct.erp.mss.pcrasr, it is referencing and using the WDJ version and not the newer WDA solution.</p><p> </p><p> </p><p>(Side Note: This “wrapper” is the reason why you might see the Adobe Form window size appear correctly for the HR Admin but much smaller for the Manager. This is because for the manager, the application “thinks” it is running inside another application and hence a smaller space. Again, there are OSS notes to correct this.)
Employee (Jumping into the Process to the Form Edit View Directly)</p><p>In this scenario, the employee will actually start the processes for themselves. Therefore, we know the employee (PERNR) as well as the process we wish to execute. Employee initiated processes are currently part of Life & Work Events configuration which is configured in the Homepage Framework configuration (ex. Address Change-US). That means it is Dependent on the XSS Java application (Homepage Framework) to handle “hand-off” of PERNR and process (in the same way as the Manager scenario “wrapper” due to limitations of eventing).</p><p> </p><p>So how do we make the start application skip the employee selection and process selection views and take us right to the form edit/review page directly? This is done by including the application parameter “PROCESS=<process name>” and making use of a special SAP ABAP proxy class in the Homepage Framework configuration.</p><p> </p><p>Please refer to Homepage Framework resources:</p><p> </p><ul><li>EMPLOYEE_LIFEWORK_BIRTHCHILD_US_SER_120.1.
If we look at one of these corresponding resource keys in detail, we see:
Therefore, if we wish for an employee to jump directly into a process, we simply pass the PROCESS application parameter. The system will pick up the PERNR (employee number) of the current user. But how does it do this?
The other part of the puzzle is the “Service” configuration portion of the Homepage Framework. Looking at this example,
Notice the “Proxy Class” defined for this service. If we inspect this proxy class,