hertenberger.co.za

In my move to make a Mac my permanent computing solution, I am busy investigating various solutions and applications I’ll need to be free of Windows. No native port of the SAPGUI exists for Mac OS X, making access to SAP systems potentially problematic. Instead, the Java version needs to be used and this has been updated by SAP about one month ago. The 720 release of the PlatinGUI for Mac OS X can be found on SAP’s ftp server. In comparison to the Windows native software package requiring at least 500MB of storage space, the PlatinGUI package is exceptionally light, requiring only the download of a single 32MB file.

There are a few base requirements that need to be satisfied before attempting the installation. A Core 2 Duo processor and 1GB of RAM is required in the target machine. From a software perspective, either Mac OS X 10.5.7 or 10.6 has to be loaded and an updated Java SE. Below Mac OS X 10.5.7, Java for Mac OS X 10.5 Update 4 is required, whilst the Java SE 6 is already present in Mac OS X 10.6. The installation was rather uneventful, creating a program icon in the Applications folder. I find the creation of new connections to be simplest under the Advanced tab with the Expert mode enabled.

Create a direct connection to the SAP system using the connection string

conn=/H/<IP Address>/S/32<Port>

The Java GUI supports almost all functions provided by the native applications. There may be one or two complex, modern transactions that may be hamstrung, but in the technical area, everything I require works without a hitch.

No trouble getting to SAP from the Apple…

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…

Yesterday, I attended the SAP World Tour 2009 at Gallagher Estate in Midrand. The proceedings of the day included various tracks, each focussing on a different aspect of the Netweaver product suite. SOA and Enterprise Services are the current marketing angles SAP is attempting to employ to get companies to spend more money.

The low-down is this: excluding SAP staff, an estimated 450 customers and partners attended yesterday’s event. Considering what it costs to send 450 individuals to such an event, the quality of information provided was abysmal. I speak only for the sessions I attended, of course. To be fair, SAP is forced to provide information at a level of a common denominator. That means presentations need to target hard-core technical people as well as those with a passing interest in a certain topic. Maybe that’s the problem with my evaluation, but I struggled to find any value in anything I saw. What’s most frustrating and annoying is the fact that that SAP still presents its products as those requiring only a few clicks with a mouse to get going.

With the exception of the SAPGUI, I have yet to see any product in the SAP stable that is simple and cheap to install. Then again, installation is not the tricky bit either: configuration of the exceptionally complex heterogenous environments is nothing short of a huge effort, resulting in a huge cost. Since individuals who attend the SAP World Tour are generally already well-versed with the SAP ecosystem, why not be a bit more truthful? Instead of showing off how easy it is to click and drag objects in the Composition Environment, why not show a true reflection of how much effort it eventually takes to get something to deliver true business value?

It’s all a marketing game, of course. But it leads to a collection of customers who get a rude shock when the software is installed and an extensive project plan has to be developed that includes many specialized resources all costing a lot of money to get the software to deliver very basic functionality. There’s no question that SAP delivers some fine backend software. It’s robust and has proven itself. But that’s not the argument.

To show presentations and disseminate information that makes the overall effort of implementation seem no effort at all is a bad long-term marketing strategy. Market your product, by any means, but stay within the boundaries of what is realistic. Implementing SAP has never been a point-and-click exercise. It’s unlikely to ever be that.

I’ve recently experienced the trials and tribulations of installing and upgrading a piece of software I’ve known for many years. Starting life as DDB4, MaxDB under the MySQL banner has gone through many hands and developers, and even more names. Developed by the University of Berlin under sponsorship from Nixdorf Computers, it transformed into Supra, Entire-SQL, Adabas D and then SAP DB. The software has has been open-sourced for a while and has been under the knife many, many times. And that shows.

A recent installation of SAP 4.6C on Windows 2003 64-bit went rather awry. Strangely, SAP 4.6C installed without issue on the default database version of its day, SAP DB 7.2.05. Even better, the subsequent upgrade of the database software completed without issue to SAP DB 7.3.04. Since I intended upgrading to ECC 6.0, I hoped to get everything running in the SYSWOW64 shell, then transferring to 64-bit later on. Everything went well until I hit the upgrade to SAP DB 7.4.3. That failed spectacularly, many times. The reason for my upgrade path is the unfortunate legacy of an application passed from vendor to vendor and developer to developer. You can’t simpy upgrade to the latest, but have to follow a complicated upgrade path. I tried many things, but could not get the 7.4.3 software installed or upgraded. SAP technical support eventually indicated they could not support my upgrade path – try the 32-bit route, they suggested.

The 32-bit installation of the same type as tried in the SYSWOW64 shell works flawlessly. But even here, there is a dangerous side effect that trapped me on the second system with a database sized just beyond a certain limit. To cater for a database restore, I ensured the target database was at least 120GB in size. Accidentally, my first successful installation ended up being in the region of 126.9GB. On the quality assurance system, I sized the database slightly larger: 129.3GB, to be precise. I don’t pick these numbers, but simply provide a MB size in case you were wondering…

Turns out anything beyond 128GB for a database segment or space is too large. But not for SAP DB versions 7.2.05 or 7.3.04. No: it’s too big for version 7.4.3 and causes the upgrade to fail yet again:

extracting: -rw-r–r–       443294 2004-08-24 20:46:41 runtime/jar/sapdbc.jar
checking unpacked archive… ok
installation of SAP DB Server finished successfully Tu, Aug 26, 2008 at 10:17:43

finding instance type…
starting release already known
migration strategy already known
running finalize check…
looking for domain user…
current database state is OFFLINE
checking parameters…
parameter check failed
cannot finish instance update for “SID”
current database state is OFFLINE
checking parameters…
parameter check failed
param_checkall
ERR
-24973,ERR_XPCHECK: param check failure/request
DATA_SIZE_0002  Constraint
17024000

On later versions, this error can be resolved by changing the value of a database parameter, thus:

dbmcli -d <DBSID> -u <dbm>,<dbm pass> param_directput VOLUMENO_BIT_COUNT 6

But of course, this parameter does not exist in 7.4.3. Thankfully I could simply restart the installation and select smaller dbspaces instead of backing up, resizing and then restoring.

It’s an important lesson for all user of open-source software: the cost of free software is not measured by it’s ease of acquisition, deployment or ability to customize its features. Instead, its real cost is often realized only when it may already be too late: it’s been deployed and the organization using it has become dependent on it.

This is an extreme case: the versions of SAP DB mentioned here have been out of maintenance for ages. Nonetheless, such software is still in active use, as my experience has taught me…

And don’t ever believe the hype that software featuring a higher version number will be better than an older one!

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…

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?

If you spend your time at different customers all running their own collection of SAP systems, you eventually end up with a SAP Logon Pad that provides no assistance when it comes to selecting the right system. Even if you name your entries intelligently, possibly including a SID, customer name and system description, you still need to scan long lists. Many SID’s may be duplicated, making a quick click launch of the SAPGUI impossible. Enter BasisTechnologies. They provide a simple application for Windows-based operating systems that reads the list of systems used by the SAP Logon Pad and allows entries to be grouped. LogonX:

The application resides in the system tray and simply hovering the mouse over the icon causes the list of systems to pop up. Select one to launch a SAPGUI connected to that system’s IP address. The 4MB download is available without charge.