hertenberger.co.za

Another typical example of the carbon interface problem when dealing with computing tasks. In this case, I had completed an interface in SAP PI to accept SOAP messages from a third-party system. Everything worked rather well until I started sending some real test messages to ensure the whole process from message acceptance to table update using my custom function module works. Not a nice sight in WE02:

The error message? EDI: Partner profile inbound not available. This is a bit of a catch-all and generally indicates that there is something missing or wonky in the SLD. Try as I might, I couldn’t figure out the problem. Clearing the SLD cache, re-creating technical and business systems, ensuring all necessary entries had been made all over the show…nothing.

The long text to the error provided a clue and I had a look at the table that contains all inbound profile information, EDP21. And there it was: I’d entered LS for some reason in the SNDPFC (partner role) field. In WE20, I removed the offending entry and saved.

Then tried again.

Problem solved.

Project Muse has been spun off into a usable product and now goes by the name Netweaver Business Client. It’s an attractive alternative to the run-of-the-mill SAPGUI, though it will suit certain users more than others. To download, head on over to the SWDC section in the SAP Service Marketplace, then navigate to the Frontend Components section. The 15MB download is quick and easy to install, though an existing SAPGUI installation is a requirement on the Windows-only workstation if SAPGUI applications are to be executed within the client.

The main aim of the Business Client is to enhance productivity and make interaction with backend systems a lot easier and prettier. The unified interface for a wide variety of business applications comprises the Shell and the Canvas, basically the wrapper and the content for all applications.

All standard applications run in the Canvas including,

• Web Dynpro for ABAP
• Web Dynpro for Java SAPGUI applications
• BI reports
• Flex content
• Adobe Forms

Web Dynpro applications should be a lot faster running inside the client due to the use of XML. PowerLists provide quicker access to difficult-to-remember SAP transaction codes. SAP’s FAQ may answer a number of other questions you may have. Find it here.

Better information is finally available that details how SAP is planning to integrate its disparate business intelligence portfolio. Having purchased BusinessObjects more than a year ago, there was a fair bit of trepidation and uncertainty in the SAP customer base. No clear path for the future solution environment regarding SAP BI was communicated, other than a rather generic and cryptic statement to indicate that further information would be made available at a later date.

That’s fair enough. The SAP product suite has grown by leaps and bounds and the addition of an entire product portfolio doesn’t help. The good news is that the strategic direction SAP has chosen makes sense: it basically consists of selecting the best of breed products from the entire portfolio, arranging solution components where they make sense and cutting sub-standard products out entirely.

The existing SAP business intelligence portfolio is billed as a complete stack, whilst the BusinessObjects product set is deemed to be open and agnostic to underlying technologies.

A single platform consisting of SAP and BusinessObjects products is to provide full access to critical information for anyone in the enterprise, from the executive to the general business person. Of course, business requirements are diverse in an enterprise.

As I mentioned above, SAP has taken the decision to integrate the BusinessObjects product range with their existing BI stack. That obviously means that certain products will no longer be maintained and will be phased out.

Here’s my opinion: SAP is excellent when it comes to providing a very robust, stable and fully-featured backend infrastructure. Unfortunately, the guys in Walldorf don’t share the same acumen with their countrymen scarcely 100km down the road at Porsche. Traditionally, anything that SAP has produced that interacts directly with the end user is rather shocking. Hardly user-friendly, generally ugly and certainly not easy to modify. The Enterprise Portal is a prime example. Sure, it’s possibly to meld it into something that reflects the look and feel a company may wish to provide its customer base and end users. But its hard work and not always easily achievable. Even the SAPGUI has only become a bit better looking since the German product made it big in the US some years ago…

With that in mind, it’s a relief to see that common sense has prevailed and that the strengths in each product suite are being exploited. Granted, BusinessObjects don’t really have much to compete in the backend space, but their user interface is nothing short of spectacular.

The speed and flexibility with which one can build interactive dashboards with Xcelsius is quite astounding. The SAP Business Explorer (BEx) is best not mentioned in comparison. The raw power and flexibility of the core business warehouse backend is the existing SAP BI system, providing cubes and other data structures together with rock-solid ETL tools.

Report Designer gives way to Crystal Reports. Web App Designer gives way to Xcelsius. BEx gives way to Pioneer. Pioneer is a new product that will provide for easier and more advanced analysis on OLAP data sources. Pioneer will replace the existing Voyager product and will provide backward compatability to legacy query views and BEx workbooks.

The strategy makes sense to me, and should provide existing SAP BI customers with a means of finally providing their end users with something they must have been yearning for for years: a pretty, easy to use front end.

And of course easy access to the data they really need to do their job. How could I have forgotten about that…

I’m busy with a business intelligence architecture for a customer. In the course of sitting down and finally getting down to writing something, I discovered the following subtle nuance I hadn’t previously considered:

Dashboards and scorecards are often confused to be one and the same. This is not entirely correct: scorecards chart progress toward objectives. The common perception of a scorecard is that it displays periodic snapshots of performance associated with an organization’s strategic objectives and plans. It measures business activity at a summary level against predefined targets to see if performance is within acceptable ranges. It displays key performance indicators that help executives communicate strategies and help users focus on the highest-priority tasks needed to execute plans. While a dashboard informs users what they are doing, a scorecard tells them how well they are doing. In other words, a dashboard is a performance monitoring system and a scorecard is a performance management system.

I don’t remember where I got it from, but it’s rather interesting…

SAP is starting to push the SOA bandwagon with a bit more vigour. For companies and individuals a bit more interested in the technicalities of Service Oriented Architecture, the new Enterprise SOA Starter Kit is a useful resource. Little more than a fancy slideshow with links to documents going into more specific detail, the Starter Kit is a 250MB download from the SAP Developer Network. You’ll need to be registered on the SDN, log on and then follow this link. The downloaded file is in RAR format, not ZIP. Get unrar here.

Remember to unpack with option x, like so: unrar x StarterKit.rar to maintain the necessary directory structure.

There’s certainly a lot of information contained in the pack, together with some interesting case studies. If you can deal with the product-specific slant (IBM and other vendors are no different), this should serve as a valuable starting point for generating a business case for a small SOA project. Remember, small and manageable is key. Also: you want to show a business benefit, not implement something for the sake of cool technology.

The idea is to take something like this

to something like this over a period of time.

Of course, theory and practice does not always blend seamlessly. Some disappointment is inevitable until this technology stack has had a chance to mature and prove itself.

A couple of enhancements have been made to the Web Page Composer component in the SAP Enterprise Portal with SPS15. Though not overwhelming, two enhancements jumped out at me.

The first is the ability to add reasonably long paragraphs and articles. In previous versions, the WPC would refuse to save the input and the text had to be cut down quite significantly. Not exactly useful if the text you want to provide to end users is of that length and cannot be changed without significant rework. The reason for the change is that the text is now stored in an XML structure and not directly in Knowledge Management as it was before.

More cosmetic in nature and seemingly limited to articles is the Advanced Paragraph editor.

Within the article editor, add a new Advanced Paragraph from the drop-down:

Now, some of the new text editing features are available. Compare the new editor tools to the standard toolbar displayed below in the image:

I’ve discovered that pasting formatted text from Word works: the formatting is retained. That includes justification. If you are using the Web Page Composer the update will make life a bit easier.

SAP software does not exactly have a great reputation when it comes to user-friendliness. Adding content to the Enterprise Portal is a mission to say the least: fiddle with adding content to the Knowledge Management component, then make it visible or link it in the Portal Content Directory. Finally add appropriate roles for the consumers of the content. It’s all a bit much. The Web Page Composer is a first attempt at making the addition and modification of portal content a lot more seamless and a lot more PC-like. End-users shouldn’t have to bother with the PCD and KM. Why understand technical detail if all you need is to update a few lines of text or add an image?

The Web Page Composer is freely available on the SAP Service Marketplace. It needs to be downloaded and deployed using the JSPM. After installation, the J2EE engine should be restarted. Once installed, users may be assigned various roles – the possibility of providing full publication access or requiring approval is possible. Users wanting to make use of the WPC require the role wpc_editor_role added to their user master. A new tab appears in the navigation ribbon for the WPC.

Of course, the WPC cannot satisfy all content requirements and is probably best used for very simple content: ideally text and images, maybe some links and uploads. For anything else, the KM and PCD has to be used, but I’m certain that SAP is moving towards a full WYSIWYG environment eventually.

Creation of a new site is a prerequisite. At present, it seems somewhat problematic to integrate existing content.

For access to the WYSIWYG magic, we can edit or create a page on that site. Effectively, the WPC provides a bunch of containers into which content may be “dropped”.

The selection of a suitable layout is possible:

Various content types may be created. There are still issues with text length – in my tests, I had to constantly chop paragraphs off the text I had pasted until the editor would accept and save my input. It is fairly easy to add images, though these need to be added to the portal content beforehand. That’s a fairly simple upload task.

Once saved, the content appears once again in the design view.

That’s basically all there is to it – now save and publish and the content appears in the relevant section of the portal.

There are still some issues with the type of content one may wish to edit or create and I’ve yet to find a way of making the WPC read existing content for further manipulation. If your end users require a quick and easy way of updating simple content on the SAP portal, the Web Page Composer may well be the way to go. It’s no FrontPage. Then again, that may be a blessing. But it is certainly a lot easier than having to work in the Portal Content Directory. In the world of SAP, it’s generally accepted that any better way is better! Regardless, this is sure to be the future interface SAP will be pushing out in future releases.

Brainstorm magazine for April contains a brief article on SOA.

Here’s part of the content:

Pardon the self-promotion And the huge image…

This is one of those typical nonsense errors that can creep in and cause hours of research and frustration to resolve. In the end, it’s a carbon-interface problem, but certainly caused only due to the human ability to parse details quickly, then assume everything else…

Why the hell software vendors can’t standardize or just stick to lowercase parameters, especially in the case of a case-sensitive environment like Java is a mystery to me. After deciding to re-generate a new certificate for the SSO connection between the SAP backend and the portal, I made the following entry:

That’s SAPLogonTicketKeyPair, with uppercase P for Pair. I kept, quite naturally, to the convention introduced with uppercase letters for each new part of that rather long key entry. But of course, the creation of that entry will have little effect and will ensure no connection is possible using the SAP logon ticket. After a lengthy J2EE restart and various attempts at testing the new certificate, I was left with a non-functioning environment. Deep within the server0 log, I finally struck upon the problem: SAPLogonTicketKeyPair should be SAPLogonTicketKeypair with a lowercase p for pair. The deletion and recreation of the key value with the correct capitalization requires a new certificate to be generated.

Then it all works again. Wouldn’t saplogonticketkeypair be more logical and leave less room for errors? Or how about some IntelliSense (or is that Intellisense) or a catalogue of permissible values to choose from?

The Netweaver special interest group had some interesting information regarding the latest releases of the Netweaver Portal, Business Intelligence and Exchange Infrastructure solutions. First off, the Netweaver Portal is due for some major enhancements, including the re-coding of many user interface elements using AJAX. The usability impact should be tremendous, and will bring the enterprise portal in line with current web 2.0 standards. Hopefully, the overall performance and response time will be improved too. The addition of AJAX is significant: until now, most access to elements on the screen required forceful clicking, then a wait for a screen refresh.

An interesting addition to the BI 7 release is a new transformation editor that is almost identical to what is presently available in the Exchange Infrastructure (XI) product. Using drag-and-drop, elements may be mapped and transformations added. The inclusion of numerous standard transformations (such as currency conversions) makes the transformation operations simpler and easier to maintain. Various syndication features permit the automated dissemination of reports to selected users at chosen time intervals. SAP seems to be standardizing on certain components to make working with different products in the Netweaver stack somewhat easier. Until now, transformations have to be handled differently, depending on whether you’re busy in BI or XI, for example.

Finally, Exchange Infrastructure (XI) is now officially know as Process Integration (PI). The term PI has been floating around for quite a while, but has not met with widespread adoption. PI becomes the engine on which SAP intends building its ESOA solutions. The primary benefit of PI is the inclusion of a range of standard, already configured content. The ESR is a vital component to ensure governance and compliance with standards and is also officially shown in the PI marketing slides.