13 Reasons why you would not want to go for HCM Processes and Forms FPM based

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