Expand +



DIY Display-Only Services

by Jacob Crane

May 11, 2010

Welcome to the first of many installments in my blog on portal and workflow technologies.

Several times in the past I have encountered clients who would like to offer ESS as display-only services.  While I would typically argue against limiting the functionality this way, we’ll save that discussion for another time.  What is important to realize in a situation like this is that we can leverage SAP’s WebDynpro personalization to create such a service without having to change code.  For many users, especially those without in-house java expertise, this is a huge win in terms of maintenance and development costs.  Today we’ll see how we can convert the ESS W-4 withholding to a display-only service without code changes.

The first step in any WebDynpro personalization is to open the application by previewing it from the PCD.  I prefer to do this from the role itself, but it can be done from the page or iView, as well.  Once opened you can control-right-click on the various elements to open the personalization menu.

The primary attributes we’re concerned with here are Invisible/Visible, Labels and Tooltips,  and Mark as Read-Only.

The first screen to modify is the overview screen.  Here we need to change the edit buttons to say “Display” and remove the delete button.  Now a user cannot delete a record but can still access the edit screen w ith the display button.  We’ll fix that edit part in a bit.

Next, we want to change the roadmap to have only two steps:  Overview and Display Details.  Again, we can control-right-click to get to the elements.

Now we can go inside the application.  We mark all of the fields as read-only and then will remove the Review button because employees will no longer go past this screen.

In a few minutes we’ve changed the standard to display-only without enhancements or code.

The tricky parts:

  1. Use the backend configuration to set the time constraint such that the New button is not available.  If you want to be lazy about it you could also hide this with personalization.
  2. Set the security role such that the access to the infotypes is read-only.  This is critical if security is to be maintained.
  3. Ensure that personalization is completed for all records.  Just because you personalize for the subtypes you see with your user doesn’t mean you’ve personalized for all of them.  It is important to create your user with the maximum amount of data (number of subtypes, types of subtypes) and personalize for all of them.  Otherwise, a user with one more record than you personalized for will suddenly see an update service.

It’s not as elegant as building a new version in Java, but it’s a lot cheaper, easier, and closer to standard.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!