Argh!!! I blurted, there are times when a developer hands are tied and he feels frustrated as he is unable meet some simple requirements. This blog is an outcome of my recent experiences with development of FPM based HCM P&F forms. This happens to be my 13th blog(so named it aptly 😆 ) and I wanted to be a critic here, but these are the things you need to watch out before you take a plunge into HCM PF using FPM architecture.

1. Form Printing – You dont have a direct option of printing HCM FPM forms, the direct web printing does not come out well and may not be accepted. The others option is to build Adobe forms and link it, this adds to your effort and you have to rely on  Live cycle designer to build the form and ADS to render the form which again would incur licensing costs.

2. Screen Manipulations/Good Layout Screens– If your form requires heavy screen manipulations like hiding, unhiding, color, text manipulations then FPM forms is not a fit, Adobe is miles ahead. For example, a customer requirement to highlight changed personal data on form cannot be met by FPM forms, there is no option to manipulate a input box to highlight in a different colour other than just hiding or making it input or read only. This can however be met by round about ways, but there is no clean solution. And many would have already noticed that the FLUID designer is a very difficult to handle workbench, and definetly slower compared to se80 or ADLC. Again if you are looking for beautiful layout screens like Adobe then you need to look somewhere else.

3. Reference Numbers – This may not be very common requirement, but some customer would definetly want to differentiate their processes using differnt alpha numeric prefixes, as far as I came to know there is no way you can identify the process inside the Badi, the Badi needs to be enhanced by SAP so that we can differentiate the processes.

4. Attachment in different Sections : In HCMPF you see the attachments on the top, but ofcourse you can personalize and make the attachments below or sideways. But if you have a requirement to have attachments in every sections so that you want to differentiate which attachment is for  which section then you hit a wall with HCM P&F.  Also added to this, there is not a way to sort the attachments based on requirements, there should have been a sequence numbering in the attachment configuration.

5. Very complex workflows – if you are in for complex workflows where in you will have to send tasks back and forth it can get very tricky vis-a-vis your custom forms since you have three different tasks and one task cannot manage all three things, I wonder why not make a single task and have a binding parameter signifying what is the stage, for example, approve, back to author etc.

6. Component reuses – Component reuse is a difficult proposition here, though you have the possibilites of composite UIBBs and detailed explanation of which you can find in Chris blogs. Data needs to be exchanged between UIBBS using singletons or other mechanisms, but sometimes the HCM PF just dont behave as you would want it to and can get you in troubled waters.

7. Editing in approval screens – This may not sound logical but customers have come with requirements of editing the form and as well as want to approve, with FPM forms the approval screen is just read only, even if you get a section editable by composite UIBB having a custom WDA you still will not able to send back the values to the ISR framework, it just rejects it.

8. Customized buttons/Work Item Texts/Customized message after submitting – If you need name your button text as per your wishes then the only option is to enhance the component and to rephrase work item texts you clone the task, I did not see another option to do this. And you will not find an option to have customized message on submission.

9. Tab out trigger – In Adobe the possibilites are immense, if you know javascript then you are your master. In WDA there isn’t an option of tab out trigger, you specifically have to hit enter. This could be big draw back when calculation on form has to happen as soon as you tab because it is quite possible that user forgets to press enter, the remedy for this is to trigger events during check or send.

10. Hiding a  button/Comments as tabular display – I am not sure if I have left any stone unturned here, but honestly I did not find a way to hide a button which has led to embarrasing situations with customer where we had to design a link to act as a button. The button cannot be hidden but the link can be hidden. You do have option to hide button if it comes with the table. There is also no easy way to display the comments in a tabular format if you want to. I think the better design would be to have it like the history where you have a more neater display.

11. Data Manipulation in subsequent steps – For some strange reasons I found that you cannot default data in next stage data based on previous stage, you can still do it by removing that field in the initial form scenario stage and making it available in next form scenario stage, but you end up with some other issues later on. The framework just does not re-initialize the data if it was already present in previous step.

12. Performance – It is a common knowledge that adobe based HCM PF have severe performance issues when the form gets bigger and FPM based ones aimed to overcome this very problem which plagued adobe, but at the end of the day you still have unacceptable performance levels in FPM forms. We compared the performance with custom WDA forms which has 10 times more data than HCM PF, I am quite confident that our custom forms were 10 times faster in rendering, the problem could lie because of the generic framework or lack of optimization of the ISRs.

13. The ever present bugs – And lastly, dont be surprised if you are hit by multiple bugs in the course of your development. Fortunately, SAP was prompt enough to suggest the possible notes for resolution and save the day for us.

Deciding the right design can make or break a project, I hope these points which I have experience would be of some help to others and bail you out from cutting a sorry figure in front of the customer, it is good to understand the limitations of a framework before you commit anything. Thanks for reading, your suggestion/comments are welcome.

regards,

raghavendra

To report this post you need to login first.

9 Comments

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

  1. Yugandhar Reddy

    We were able to develop complex applications without much compromise using FPM based HCMPF. If we compare Adobe and WDA apps, they are different, appropriate technology has to be used based on the requirements.

    (0) 
    1. Raghavendra Prabhu Mithal Post author

      Thanks Yugandhar for reading the blog and commenting on the same. Though we were able to develop relatively complex applications, this framework has some inherent shortcomings. but I know we can enhance and play around just like what you did in your blog, thanks for that informative blog on pop up.

      (0) 
      1. Yugandhar Reddy

        Yes I too agree there are few issues, WDA HCMPF is new, so we can expect few issues in the beginning, SAP too is coming up with several notes and trying to address them. For hiding buttons etc may be we have to wait for next big release.

        (0) 
    2. Sahir Nidagundi

      I agree with you Yugandhar Reddy.

      Thanks for sharing Raghavendra. I do agree on several points but with respect I have different opinion on several points.

      1. Form Printing – There is limited support for this… refer here

      Print Support For FPM in HCM Processes and Forms

      2. Screen Manipulations/Good Layout Screens– Many of these things are possible with the feeder class.

      3. Reference Numbers – This should be possible as well , though I have explored it.

      5. Very complex workflows – This depends on the expertise of the workflow developer.

      7. Editing in approval screens – As per SAP Approval step is meant to be a display only scenario.

      8. Customized buttons/Work Item Texts/Customized message after submitting – This is possible with feeder class and other modes.

      9. Tab out trigger – Agree.

      10. Hiding a  button/Comments as tabular display – Could be achieved with feeder class enhancement for list  or form as the case is.

      11. Data Manipulation in subsequent steps – This is very much possible using generic services.

      12. Performance – In my experience – since there are is no ISR layer involved the performance with FPM forms should definitely be better. Please relook at the generic services.

      13. The ever present bugs: True

      Regards,

      Sahir.

      (0) 
      1. Raghavendra Prabhu Mithal Post author

        Hi Sahir, Thanks for reading the blog.

        1. Form Printing – There is limited support for this… refer here

        Print Support For FPM in HCM Processes and Forms    – this is what I was refering to in my blog, you have to design a new adobe form for this.

        3. Reference Numbers – This is not possible with current BadI given there is no parameter, may be possible with a code break.

        4. Screen Manipulations – SAP recommended approach is through generic classes UI_attributes, so in that sense it is not a possibilty. I think it is a basic requirement SAP should provide.

        5. Very complex workflows – We had workflows with 25 levels of approvers and it can be taken from any stage to any stage in workflow, working with 3 different tasks makes it unnecessarily complex.

        7. Editing in approval screens – Customers demand that because their legacy can do it 🙁

        10. Hiding a  button – I dont see any option to do it as the button cannot be bound with my generic class at all.

        11. Performance – If you compare with previous adobe forms it has increased many times but still it is very sluggish and customers have raised concerns.

        (0) 
  2. Satyendra Kumar

    SAP is not replacing Adobe based Form with FPM based form. This is an additional option available, now with this customer has more flexibility to choose the technology based upon their need. Both the technologies has their own advantages/disadvantages.

    In one technology you have better printing, scripting support.In FPM based form you have better value helps, better integration with form designer no additional license, no ISR layer, better performance etc. 

    (0) 
  3. Satyendra Kumar

    You do not need extra license as you are not using Interactive forms in case of FPM forms. Moreover if you are using print functionality and creating print forms that will also not applicable for extra licensing. However you need lifecycle designer and other necessary infrastructure required to use this.

    (0) 

Leave a Reply