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.

I’m quite accustomed to using Altova’s XMLSpy for testing web services and SOAP calls. With the last installation of Windows 7, I forgot to re-install XMLSpy and was in a bit of a fix wanting to test a SOAP call to SAP PI.

Open-source and free software has an undeserved reputation of being complicated and less useful than a commercial product. With soapUI, nothing could be further from the truth. Compared to the Altova product that costs a huge amount of money, specifically when the SOAP testing function is required, the free soapUI performs the task of web services testing with aplomb and significant ease.

The user interface is well-designed and features a number of nifty features to hide and show pertinent information. With a WSDL in hand (or saved to a file), it’s remarkably easy to create a scenario for testing.

Import the WSDL definition, tweak some specific settings such as user names and passwords and have the payload transferred to the target. It’s an indispensable tool for the interface developer working with SOAP interfaces to and from SAP PI, for example. It’s obviously unable to provide assistance with stupid configuration errors the carbon interface in front of the screen is responsible for.

soapUI is a classic example of a targeted application that provides a solution to a single problem and does so very well. The features of soapUI can be summarized rather briefly:

• inspecting Web Services
• invoking Web Services
• developing Web Services
• Web Services Simulation and Mocking
• Functional, Load and Compliance testing of Web Services

For more advanced users, a professional edition is available for sale. The price of the commercial software package approaches that of Altova XML Spy, but for everyday use the free version is more than adequate.

If you have a requirement for a great web service testing tool, soapUI should be on your download list.

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…

It’s been many years since I last ran an SAP upgrade. In the days of 2.2F, upgrades were a lot of fun, took many days and required a bit of thinking. A seven day upgrade was a challenge and made you feel like you’d accomplished something! Nowadays, it’s a question of swapping DVD‘s and answering questions posed by the guided procedure. Of course, that’s all good and on the whole, the PREPARE and SAPUP programs perform admirably. Except, I’ve had a heck of a time with the Java runtime to allow me to use the Upgrade Assistant. Not only with the upgrades I’ve had the pleasure of piloting in the past two weeks, mind you. The same nonsense occurs during the installation and maintenance of the portal. It’s a bad reflection on the much-hyped write-once, run anywhere model the Java virtual machine was supposed to provide.

My overall experience with Java has hardly been positive. Even worse is the odd mood and glaring inconsistencies the software seems to show: so, for example, I am able to deploy a JRE version 1.6 (not recommended by SAP) to run the Upgrade Assistant during an upgrade of a 4.6C Oracle system on Windows 2003 to 4.7. The Upgrade Assistant works happily and there are no glitches. I used that version simply because I had no access to anything else. That same JRE fails to make the Upgrade Assistant function on a 4.6C MaxDB system on Windows 2003 that is a candidate for an upgrade to ECC 6. But, the recommended versions in the version range 1.4.2 refuse to work, too. In the case of 1.4.2.13 the Upgrade Assistant starts but throws an error almost straight away:

SAP note 941595 provides a link to a URL on the Sun site where a much older Java version can be downloaded. Why can’t SAP provide a tried and tested Java runtime or SDK in the upgrade pack? It’s incredibly frustrating to install and uninstall Java runtime components to try and get a non-critical software component up and running. As a command line fan I’m very happy to simply run all my upgrades with mode SCROLL:

It recaptures that authentic SAP upgrade mood. Who the hell needs a GUI for an upgrade in any case?

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?