My very own EP6.0 Wish List – Getting ready for XMAS

There is much I love about the new EP60 infrastructure but there are still a few areas that continue to frustrate and confuse me. So here is my wish list in no certain order:

1. Implementation and support of Single Signon to the Portal without requiring an IIS server in the landscape.

One of the things we love about the EP6 infrastructure is that it will run on our standard HPUX platform. We will significantly reduce our support costs by reducing the number of servers and the number of Operating Systems we have to support. But we love having Single Signon to the portal and we simply can’t live without it.

The current solution is to run an ISAPI filter on an IIS server to handle the Integrated Authentication and then redirect the traffic to JAVA portal server. This is a less than perfect solution because:

a.) You don’t need just one IIS server, you have to have at least two to deal with failover. This also requires you to deal with load-balancing of some kind and all of the infrastructure costs associated with supporting it. b.) The current implementation using the filter seems very flaky and has not worked dependably for us. We have SAP looking at the problem but frankly our confidence is shaken. c.) All of the traffic between the Portal Servers will have to pass through the IIS servers (via the ISAPI filter) providing an additional bottleneck.

A JAVA only solution that mimics the capabilities of Integrated Authentication is not that difficult to do (we have built a prototype but it has not been blessed by SAP)and would really simplify our landscape and support costs.

2. User tracking and reporting

Our customer’s are crying out for information about how many users are logging on to the portal and what they are doing once they get there. While there are some 3rd party tools that can address this, they require a great deal of analysis and logging levels we don’t want to run in a production portal. Not to mention, they are often quite expensive.

What we need is a built-in ability to track user logon/logoff and what pages they are going to. Perhaps we could have multiple levels of tracking to reduce performance impacts (i.e. we could turn on detailed tracking for a short period of time and a more general tracking during the rest of the time).

This capability is key to a number of things:

a.) Billing our customers by their customer usage. b.) Improving adoption by improving the User Interface design (we would be able to see where users are struggling to get information). c.) Reduce system complexity by eliminating unused capabilities. d.) Identifying training needs based on usage patterns e.) And a whole lot more.

We made some reporting tools availible on SDN in the Download area, see if these help your reporting issues.

JW

Portal Usage Reporting

An important part of a portal project is following up on the effectiveness of the portal pages design and usability as well as transaction volume. The following metrics provide the minimum necessary information for this kind of analysis: