Skip to Content

EP6 SP12 XML Forms Hack – Not SAP Recommended

So, we’re in the midst of doing our upgrade to SP12, and it has been nothing short of bug-filled. SP12, although a far superior product to SP9 and predecessors in the Enterprise Portal realm, has alot of undocumented features, otherwise known as bugs – from an SAP customer perspective. For one, you’ll probably notice that a number of iViews, that use the ‘’ web component, and usually refer to a ‘…ListShow.xsl’ file to list content items instead uses the ‘…ListEdit.xsl’.

Well, I found that if you simply overwrite the ‘…ListEdit.xsl’ file with the ‘…ListShow.xsl’ in the corresponding XML Forms project, that fixes it. Although, we have one slight problem now, how do we display items for editing. Does the word ‘Ooops’ mean anything to you? Well, the only path to solve this now is to build a copy of that XML Forms project and use the original copy of the ‘…ListEdit.xsl’ file for editing, and the project you modified for displaying the contents.

Part of this problem is due to the fact that the ‘…ListShow.xsl’, according to SAP is no longer supported, and that a new file called ‘…RenderListItem.xsl’ is used. I’ve no deep information on this – I think this will become available in time. SAP really needs to let customers know about these rather than us having to go through OSS notes in order to discover these deltas between service packs – its frustrating and it really can challenge the credibility, not only of SAP, but the customers that use their products. The situation was so bad here prior to me figuring out this little hack, that there was the risk of executives shutting down the upgrade to SP12 and us having to stick with a rather flaky SP9 install.

And, to add salt to our wounds, we’ve gotten two rather quick responses from OSS stating for us to skip SP12 and go straight to SP13. I know it is virtually impossible to predict every little bug that could occur when testing an upgrade, but with proper regression testing, something as obvious as this bug with XML Forms, can be resolved before a service pack is released to customers. We are under pressure to deliver. And, when we are upgrading your (SAP) product, based on your recommendations, and suddenly we have to deal with a whole new set of bugs that hinder our development, the business (the customers of our portal team) lose faith in us. Even worse, there’s always turf wars in IT departments, ’cause different groups are technology-centric, and amidst all the political bickering, if one group is not delivering, other groups use that to their advantage. I don’t want us to lose the battle, because we have to deal with variables beyond our control, especially being portal developers.

Anyhow, I’m sure I’ll have more stories to tell about Ep6, so stay tuned. And, if my weblog seems too emotional, just disregard that – that’s just me – being so passionate about my work, and always worried that my job is on the line. ‘Hope this little tidbit is useful to you!

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

    both kind of forms are very old; their birthday has been before FlexibleUI has been introduced. To render lists of XML forms (more or less: overviews), you could use these forms, but nowadays, with FlexibleUI, you have the commands created by the LayoutSet (and it's collection/resource renderer and the commands defined for them), using the RenderListItem.

    See as well as /thread/3277 [original link is broken]

    Hope it helps

    • Great information.  'Much appreciated, Detlev.  Timing-wise, we've resorted to just falling back to navigation iViews that use the out-of-the-box explorer-style layout and just assign the appropriate xmlforms project to the associated paths in KM, through Forms Based Publishing.  Once we've practiced and proven the use of the RenderListItem form, we'll likely make that part of our standard going forward, especially if that is SAP's direction.  Again, thanks!
  • Well, the best way to resolve the issue on the XML's being displayed in edit mode, is to create a message to SAP, and they'll send you a XML API wich resolves this. I believe this will be covered in SP13.
    • Excellent point.  I agree we could, but we've enough issues with SP12, that we'd likely not implement such a fix, unless it was part of an official service pack.  And, as you can see in my weblog, SAP has already recommended going to SP13.  Right now we are somewhat regretting throwing in an upgrade in the middle of major project work which is to be completed by the fall.  Had we waited, we could have probably avoided these unnecessary pains and delays.  Oh well, I guess if the powers that be want an upgrade, we give it to them.  That's life being the little man in a big company.