Skip to Content

Web Dynpro Forms using HCM Processes and Forms

Like the idea of HCM Processes and Forms but not so keen on Adobe Interactive Forms?


There are other options! It is possible to enhance the HCM P&F Framework to cater for Web Dynpro based forms. The enhancement to the HCM P&F framework creates an alternative route and loads a custom Web Dynpro based form while still entirely utilising the HCM framework and all of the functionality that it offers, such as user events, validations and much more. This can be done using the SAP Standard Enhancement Framework available to Web Dynpro ABAP. All enhancements are recorded in the Enhancement implementation. Absolutely no modifications to SAP standard objects are necessary. Enhancements implementations can be easily activated or de-activated if necessary using the Switch Framework.


The only real change is around the UI layer and how the information is presented to the user. The framework and backend logic remains the same. The configuration around the HCM Processes & Forms Design Time remains the same and the Web Dynpro based forms will continue to use the settings in the config in the same manner as the Adobe Interactive forms are using them. In fact, you can even convert existing Adobe Interactive forms into Web Dynpro forms using the same config as the Adobe Interactive Form. This does not have to be a replacement for Adobe Interactive forms, but can be used in conjunction with Adobe Interactive forms.


Any Web Dynpro ABAP UI elements can be used within these forms, such as tabstrips, roadmaps, Collapsible Trays, Groups and even flash islands if that was required.  Tab strips, roadmaps or collapsible trays can make it easier for the user to navigate within extremely large forms. Standard features in the Web Dynpro ABAP Framework can be used, such as F4 search helps, field validations and OTR (Online Text Repository). UI control can be handled easily via UI element property bindings and the use of action handlers. The WD form can also fire user events to be handled by the backend just as you would in an Adobe Interactive Form.



The SAP Standard Adobe Interactive Forms route

Start the standard Process Execute application HRASR00_PROCESS_EXECUTE



Search for an employee using the standard employee search screen



Select the Bonus Payment process in the standard process selection step



The Process Execute application then loads up the Bonus Payment Adobe Interactive form.



The Web Dynpro Forms route

Now going back to the Process selection, this time select the Voluntary Terminations process which has been setup in configuration to be a Web Dynpro based form.


Now still within the Process Execute application the Adobe Interactive form is now replaced by a Web Dynpro ABAP Form.



Due to the size of this form it has been done using Tab Strips to avoid the need for scrolling. Note that as part of the enhancement a print button has also been added that loads an Adobe print form in a popup window.



In the print form popup the form can now be printed or saved if necessary



The user can then hit the “Check and Send” button and submit the process for approval, utilising the framework and workflows exactly the same as an Adobe Interactive form would.


This process works perfectly end to end and performance on the Web Dynpro Forms is quite impressive.

You must be Logged on to comment or reply to a post.
    • Hi Brad

      Excellent blog. I wondered how long it would take before the interactive form (and hence licensing issue) was taken out of the equation. I must admit I always thought that a Flex front end would be offered at some point.

      Indeed, a very interesting and thought provoking blog. I would also be very keen to learn more about how this was achieved.


    • Hi everyone,

      Thanks for the comments and for taking the time to read this blog.

      Here's a bit more info on how it was done:

      I began by debugging the standard SAP HCM P&F web dynpro component HRASR00_PROCESS_EXECUTE to better understand how the framework works, and discovered that the core of the framework lay in the web dynpro component QISR_UI. So after debugging QISR_UI, I discovered that it can be enhanced with "relative" ease to create an alternative view to load up a custom web dynpro component instead of the view that displays the interactive form, based on whether the form scenario is configured to be an Adobe Interactive form or a Web Dynpro based form.

      My goal was to make this enhancement as lightweight and clean as possible, leveraging off the standard functionality offered by the framework as much possible. In theory, this enhancement is pretty much just a change to the UI layer, everything else functions as usual.

      In order to be able to dynamically load any web dynpro based form at runtime depending on which process was selected, I found it necessary to create a web dynpro interface that is required to be implemented by any web dynpro based form, in order for it to be recognized by the frame work. This allowed me to define the web dynpro interface as a usage in the enhancement, and embed the interface view in my custom views view container element. And at runtime I can create an instance of the relevant form based on the process selected.

      Hope this answers your questions. I hope to post more blogs on this topic in the future where I can discuss it in more technical detail.

  • Great post!  I've been reading a lot about this lately around the area of HCM PF.

    While this approach gives you the ability to build custom web dynpro for ABAP screens there are other alternative UI's available. 

    1) AspireHR ( - Screens are built dynamically at runtime based on configuration.  While there are some drawbacks such as, zero scripting, can't customize the screen as much... I believe there are indeed some notable advangates.  Namely, there is no need to develop a front end it's all done for you configurator.

    2) AragonHR ( - Replaces the adobe form with a custom Adobe Flash/Flex UI.  It's new and it seems to have some fancy bells and whistles like embedded org charts, videos, rich tooltips and more.  I would imagine the benefit here is the flexibility to do whatever you want on the fronend.

    All these solutions leverage the HCM PF framework 100% which is great.  The one on this blog sounds more like AspireHR's technology but with a bit more flexibility (along with more work)?

    Sounds interesting, keep it coming!

    • Hi Andrew,

      Thanks for your informative post. I am aware there are other alternatives. We did actually look into the AspireHR solution prior to deciding to come up with our own solution. I was not personally involved in the discussions with AspireHR though.

      The specific customer this was developed for required the flexibility that you could only get from developing a custom Web Dynpro Component. They have only opted to go with the Web Dynpro forms options for the extremely complex and large forms, which would have been 4 - 10 pages or more if they were done in Adobe Interactive forms. All simple forms of 1 -2 pages were developed as Adobe Interactive forms.

      I did experiment a bit and wrote some code as a prototype to dynamically create the screens at runtime based on config, similar to the AspireHR solution. And it is definately a viable option for simple forms. But would never be able to cater for forms with extremely complex UI control.

      The route we have opted to go, is by no means a shortcut to developing forms, and will still require roughly the same time to develop as an Adobe Interactive Form. It also requires a developer with Web Dynpro ABAP experience.

      When doing research prior to developing this solution, I found it hard to find much information about this on the internet or SDN. So my main purpose of this blog is to put it out there in the open and raise awareness and interest in the different possibilities.

      So thanks for your input about these other alternatives!


    • You do identify one key differentiator which is the ability to transfer data into PDF's.  I'll say thats a nice touch.

      But also, it's more improtant to identify the what distinguishes both solutions.  AspireHR is mostly configuration so you can't control what the screen looks like as much as you can with what is proposed in this blog.  From a development and usability perspective I'd say thats by far the most notable advantage to pursuing the development detailed here.  Of course, there would be far more development and support that comes along w/ that.

  • Hey Brad, Amazing presentation! Infact there are many customers looking for this with minimal effort, Also do you think are there any limitations with your new implementatin?
    How many customers have already done your approach if i may ask?
    • Thanks Siddharth!

      We have recently gone live with the first customer, which has gone very smoothly and has been a great success. This customer decided to go with Web Dynpro Forms for their 4 largest processes and did the remaining 10 processes as Adobe Interactive Forms.

      I dont believe there are any limitations to this approach thanks to the flexibility offered in Web Dynpro ABAP.

      Taking into account that the QISR_UI Component was designed to work with an Adobe Interactive Form and not an embedded Web Dynpro Component. The data is being formatted in such a way to cater for the Adobe Interactive Form Interface. So the the Web Dynpro Form Components' context needed to be designed to replicate the structure of that Interactive Form Interface.

      I wouldnt say this is an easier approach than Adobe Interactive forms, but it definately isnt a more diffucult approach. It would probably take roughly the same amount of time to create a Web Dynpro Form as it would to create an Adobe Interactive Form.

      If you have any other questions, I'd be happy to answer them.

      • Thanks for replying! we were thinking of other UIs as well, But your approach is cleaner, Lets see here in america some customers wants to implement it.
        I am happy that you shared your immense knowledge. Again Good work, Keep Contributing!
  • Very well done. Sorry for just now commenting on this...I just found it. Myself and some other HCM P&F folks tried to start the habit of naming blogs starting with: "HCM Processes & Forms:" so they would be easier to find on here. In any event...a few comments and questions....

    First, again great blog! I was hoping someone would post this. I know of at least 3-4 other companies offering different variations of this (much like the AspireHR "product"), but it really isn't that complicated for customers to do themselves. Hopefully, SAP will come to terms with a more reasonable licensing model for Adobe IF when used with HCM P&F that will make this another option vs. a budgetary necessity. We sat with both the SAP and Adobe product leads and mentioned this yet again at Vegas TechEd 2010, but really got very little info back other than what is's too expensive! haha

    Which leads me to the next part...I guess for me, I was hoping to see some detail in a "code monkey", I wanted to see WHAT you extended, how you extended it, and how you see the View as the form replacement (in config or in code?) to manage later. Blog #2?

    Thanks again!

    • Hi Chris,

      Thanks for the positive comments and feedback. I will use that naming convention for future blogs.

      I am aware that there are other companies offering this as a product such as Aspire HR. And as part of the project that I implemented this on they actually approached Aspire HR whose product was too costly and not flexible enough for their requirements.

      I actually don't have any knowledge of how these other companies went about their enhancements from a technical perspective. So would really be curious to know how they went about doing it and how it compares to how I have done it. As we all know, give 100 developers the same task, you will probably get 100 different solutions that do the same thing. Some similar to others, and some technically more efficient and better designed than others.

      Having the knowledge that others have done it before definitely helps in knowing that you are not attempting an impossible task.

      I would be happy to share some technical insight into the solution. For this I do think it is appropriate to write a "part 2" blog concentrating on the technical side of it. But just to give you a starting point in the mean time until I get the time to write this. The entire enhancement is within the QISR_UI component.

      I will do my best to get the next blog out asap.


      • Brad, your thinking is spot on! Yes, there are probably many ways this can be done. Heck, even I thought up quite a few when I saw "how" SAP implemented the form exchange with the ISR framework (in fact, I worked around (with?) this to do a Blackberry solution I blogged about haha).

        I am now GREATLY looking forward to part 2 of your blog! Don't keep us waiting.....and thanks again for blogging!

    • Hi Siddharth,

      While investigating and figuring out the best way to classify a form as a "Web Dynpro form" opposed to an "Adobe form", that was one of the routes I looked into. in transaction QISRSCENARIO I started going the route of a fixed value append to domain QISRDPROCESS_TYPE and adding a new value fixed value 'W' - Web Dynpro Forms. It ended up that it would need a bit more work than just that. And I was advised that much of the data in view V_SCENARIOVERSN was populated automatically via transaction HRASR_DT opposed to QISRSCENARIO, so it wasnt the best way to do it via that field.

      In the end due to time constraints it was decided by the client that they were happy to do it via naming convention. So all forms starting with "ZWDF" were regarding as web dynpro forms, otherwise they are dealt with as Adobe forms. I know, not as impressive as you were expecting 🙂

      If this were to be developed as a packagable solution for resale, I would definitely spend some more time finding the most appropriate way to do it via config with minimal impact on SAP standard. Any suggestions welcome. Naming conventions like this is something I generally try and avoid, but it was requested by the customer and necessary in this case due to time constraints.

      Hope this answers your question. If you decide on  an alternative I'd be keen to know.


  • Hi Brad,

    Thank you for the blog, it is very helpful.

    Can you please answer my few queries regarding:

    1.At which iveiw method( HRASR00_PROCESS_EXECUTE ) you are able to call your custom webdynpro component.

    2.Is the Custom webdynpro able to embed into the view after selecting and processing.

    3.Is the adobe logic helps us in implementing the Custom webdynpro component.

    Please help with your views on the queries.

    Thank you, Kishore