9 Posts
Tobias Hofmann


Posted by Tobias Hofmann Mar 26, 2015

I stop using SAP Community Network as my go-to blog platform. From now on I will publish all my blogs on my private site: On SCN I will post a shorter version of an SCN worthy posts.




In case you followed my activities on SCN this should be of no surprise. I stopped posting in the forums years ago, and looking back at the last 3 months, I published almost no blog.


Since the very beginning of “new” SCN I had problems logging in, staying logged in, creating content, having control over my content, using SCN somehow as a place for a digital identity in the SAP world, accessing content from a mobile device, etc. Support from SCN was always top notch, especially from Oliver Kohl. In the end what counts is the overall UX, and when a basic action like logging on is not working, a blog post is lost after loading 4 images (no session found), things that I simply expect to work from a site like SCN do not work … Some of these problems caused me to stop participating in the forums, leaving me basically as a blogger on SCN.


SCN is working on creating a new SCN and taking a look at the announcement made until today, they are on the right track. So why do I not simply wait another 6 months?


Hosting my own site give me foremost insight to who is accessing it and control over my content. Publishing a blog is easier; I can use the site for other stuff like document sharing too. And it works on a mobile device. In 2015! I can have subdomains, link to it without having to fear that someday a URL will change. Short: I can use my site as a home for my digital me.

Of course this won’t be without problems. My site is running on a Raspberry Pi. Lucky me: I bought a model B+, just two weeks before the new model was announced. No 1 GB RAM or multi core for me. The uptime depends mainly on my energy provider (Light): don’t even think the computer will be up and running 24/7 for just one week. Access is HTTPS (TLSv1.x) only. Not only because of security, but because that’s the only port allowed for remote access by my internet provider. You can see, my site comes with a good level of geek factor J





*The real reason why I will continue to post from time to time on SCN is: I am close to 15.000 points or being 2 digit in the all time SCN rating. At least one of those I want to reach!

hairlengthcompetition (1280x960) (1024x768).jpg

In my BIF contribution, I mentioned that my son nowadays does a large part of my contribution to SCN. Laure Cetin found this out and while I feared that I‘d lose my topic leader status, what Laure did is quite the opposite. Dedicated to SCN as she is (true inspiration) she handed me out this instead:


Certificate of Appreciation for Sebastian Hofmann, SCN Topic Leader 2012 in the category: Youngest Contributor.


I am such a proud dad! (even when Laure was not aware of it, but that was a really cool birthday present she gave me).


Now, before you start thinking that we are making jokes about the Topic Leader status: au contraire. This is a really amazing example why I am active on SCN and what keeps me continuing contributing: we are a community. With community, I mean community and not an online site. It is not as if I have weekly meetings with Laure. In fact, this is the second time in 2 years that I have met her in person. SCN is the glue that bring people from the SAP ecosystem together. It is not only for getting answers for SAP related questions; here you can make friends and connections that go way beyond business. Members know each other, we respect each other, and we laugh together. That is what I love about this unique community. We create it; we are SCN.

In my personal backlog I have a large list of blog topics I think are of interest for the SCN community. Some of them are already laid out or almost ready to be published. As SCN is about community I thought: why not let the community help me decide what blog I should focus on next. So, here is my backlog, feel free to comment:

  • Load testing web applications
  • Expose BAPI as REST-full JSON: done
  • Debug SAP Portal applications
  • Continuous Integration
  • SAP UI5 in general and phonegap
  • Apache ESME installation in NetWeaver CE 7.2
  • Setup a Java development environment that does not include NWDI
  • Compare performance of NW Gateway oData with CAF + JSON

As you can see, not much about SAP Portal 7.3, on device portal or NetWeaver Cloud Portal, but that is on the backlog of my backlog :-)


Update 1: Expose BAPI as RESTful JSON is published.

Update 2: Load testing web applications with ab: part 1, part 1.5

Update 3: Continuous integration

On demand is the “next big thing”: every product, every solution has to be available as an on premise and an on demand version. Simplified, on demand means that you can access your solution via the internet, from everywhere you are. For a normal user there is no difference in how to access a new on demand solution and how Google Mail is accessed and used: enter the URL in the browser and start using it. For some solutions on demand is more a cultural shock than for others. Basically the main benefits for on demand are access, costs and maintenance.

SAP Portal users are familiar with web enabled access. Most of the time they are bound to the corporate network; sometimes they can access the services from outside the corporate network, by VPN or even by a “normal” URL. So where are the benefits of an on demand portal (ODP)? Configure your infrastructure right and you can have an on demand version.

The tricky part is the “your infrastructure”. Not every company does know how to do it right or even has the skills to do so in a secure way. The technology stack needed to run the SAP Portal is NetWeaver Java. There are stacks out there that are easier to maintain and that need fewer resources to run. You need a full J2EE stack for you application? Most portal applications only need a servlets container (like tomcat). The framework and standard UI of the SAP Portal are too heavy for Internet usage. Even with the External Facing Portal (EFP) framework, light weighted is defined differently. Licenses for the SAP Portal are cheap when your users are Business Suite users; costs like bandwidth and maintenance remain.

But still: problems that can be solved, so why an on demand portal?

Maintenance is where Basis surely will be reliefed as the task for applying service packs and notes will be delegated and end-users will be happy too as a good on demand solution offers a higher availability than the infrastructure of a normal company can. Setup time and costs are inexistent compared to the on premise portal.

The ODP will be – naturally – an external facing portal (EFP). Considering the problems the on premise portal has when it comes to make it an EFP in regards to:

  • Browser support
  • Mobile support
  • Security
  • Speed
  • Access

How will the ODP treat and solve these problems? And when you are an EP user, what kind of options will you get to use the ODP as your EFP? And will the ODP be the starting of the end of the EFP of the SAP Portal?

Looks like SAP is going to use the on demand portal to introduce a new stack to run the portal on. Open source based, OSGI support, something more like tomcat. The connectivity won’t be able to compete with what the SAP Portal offers, but as long as your backend exposes the data using HTTP/S it can be integrated; implying that you still have to be able to expose your backend data in a secure manner. If you know how to do that you can still opt for opening your corporate SAP Portal. But you won’t get the new SAP UI5. And that new interface alone justifies the on demand portal. Compared to the “old” SAP UI, UI5 was designed to be used over the internet in mind.


What do I expect from ODP?

A new software stack, cleaner, easier, more open source and support of more and newer standards. The new SAP UI5. If everything works out well SAP will be forced to merge the two code lines of on demand and on premise portal. Refreshing the “real” SAP Portal too. What can be wrong about that? Mobile access is crucial. Of what help is a portal accessible from everywhere and you need a desktop browser? This should also drive the adoption of mobile access to SAP and thePortal on device for the on premise SAP Portal.

As ODP gives us a revitalized portal running on new technology it should attract more developers. Done right developers have the freedom to choose how and with what they want to code: GWT, jRuby, PHP for Java, JSF, Java 5, 6 or 7, etc.

How will the access to information handled? A portal with portlets is just the visible interface to the user, but what about portal services? Everyone that already had to integrate the on premise portal – or the information stored and made accessible there – into another portal or product know that the SAP Portal is meant to be the last point of access. The SAP Portal’s primary design is to integrate content, but not to share it. Specially an ODP cannot be designed that way. As it is available 24/7 to everybody, so has to be the information. Will ODP come with a predefined architecture for accessing portal services and data? A possible way can be XSLT: content templates in XSLT can use portal services and classes to create the content. That way, all the information that is going to be displayed has to be available as either a service or a consumable Java class. And who says that you need a browser to access a portal? With desktop applications or open social the ODP can be integrated to serve the user in an inovative way.

One problem remains: Developers. SAP has shown us more than once that this is a topic where SAP continues to deliver below the expectations. Currently, developing for and learning SAP on your own private environment comes with some constrains: downloading, installing, renewing the license every 90 days, and you cannot create your environment as you wish, you have to use what SAP gives you. (ex: CE 7.2). Not everybody can download several GB of data and install it; the hardware requirements are even today still a challenge for laptops – not everybody has more than 2 GB memory installed. Contrary to this, tomcat is downloaded and running in minutes. No wonder that tomcat is a popular servlets container.

For the developer ODP is portlet development (WAR). It will be interesting to see if portlets developed for ODP also run on a native tomcat or on JBoss or on other competing products or what the effort is to make them compatible.

It lies in the nature of on-demand that access to the software isn’t a real problem anymore. The question is: will developers get free and no time limited access to ODP? To evaluate, learn and code the access does not need to be unlimited in all aspects: 1 or 2 users, limited bandwidth, CPU and memory usage, performance also does not count much, data base can be SAPDB. What counts is: give access to developers, from the very beginning.

The SAP Portal is a product that - by its nature - is accessed by a browser. The SAP Portal supports the use case of an external portal so it can be accessed by several browser types. And the market is full of browsers, to just name a few:

  • Internet Explorer
  • Firefox
  • Opera
  • Chrome

And every browser is available in several versions and flavors (desktop / mobile). The most common browers used by companies are Internet Explorer and Firefox. As Firefix (FF) 3.6 is out since several months and soon will get replaced by Firefox 4 I wanted to update the portal's SPS to get support for the latest version of Firefox. Why Firefox? Firefox is a widely used browser that is adopted by many  companies and that adheres to web standards (W3C) and (many) end-user  prefer it over the Internet Explorer. So I planned to do an upgrade to a newer SPS of the portal to at least EHP1 SP8 ( to get support for FF 3.6.

Reading the Open Source at SAP in 2010 I thought this should not be a problem. Until I read the PAM: no FF 3.6 support. It looks like this isn't even on the roadmap for NetWeaver 7.0X.

Release history of Firefox:

  • Firefox 3.5 was released on June 30, 2009
  • Firefox 3.6 was released on January 21, 2010. That's almost one year from now.

Source: Wikipedia

SAP Portal added support of Firefox 3.5 in January 2010 (almost 6 month after the release of FF 3.5). More than one year after the release of Firefox 3.6 there is no support for this version available.

Without the support for Firefox 3.6 in the latest SPS I'll have to wait for the next SPS that hopefully will include support for a recent Firefox version. The problem with the missing Firefox support is:

  • End-users will have to use FF 3.5 and when the (companys) browser gets updated to FF 3.6 you'll loose support
  • When Mozilla releases Firefox 4.0 they will shortly after drop support for FF 3.5, and because SAP won't support a product that the vendor is not supporting, the support for FF 3.5 by SAP will also stop.

It looks like Mozilla wants to maintain FF 3.5 at least to February 8, but End of Life for FF 3.5 was already announced and planned for August 2010. Short: luckily for Firefox users, Mozilla had to delay FF 4. If not, there wouldn't be support for Firefox in the SAP Portal. As a company that wants to use Firefox with SAP Portal, you are forced to run an old and no longer recommended version of Firefox ("All users are strongly encouraged to upgrade to Firefox 3.6")

This is leaving me with one question: Why is SAP not going to support FF 3.6?

There is hope: In 7.3, Firefox 3.6 will be supported. As 7.3 is in ramp-up it isn't available to all customers. This typically needs around 6 months after the product entered ramp-up.

  • Where the developers focused on the NetWeaver 7.3 release with no time to make the current portal Firefox 3.6 compliant?
  • Is Firefox not considered as a browser that customers are using?
  • How does this fit into the Open Source@SAP announcements? 
  • How can you run an external facing portal with SAP Portal when the portal isn't supporting the most used browsers like Firefox and Chrome?

The support of Firefox from SAP leaves you with more questions than answers. In the PAM for 7.3 there is only FF 3.6 mentioned. Will this be downported to older releases as well? What about FF 4? When 7.3 will leave ramp-up and FF 4 is already available, how long will it take to gain support for FF 4? Will this be included in the final version of 7.3? Or do customers need to apply shortly after a new SPS to have FF 4 support?

What is on my browser support whishlist:
- Google Chrome
- Firefox 4
- WebKit
- Opera
- Mobile Browsers

From time to time I like to check the job market to see what I'm missing. With the SCN Career Center this is easy: just click the link in the SCN top level navigation and start searching.

First I checked the SAP Portal demand for Brazil. Well, I tried to search for all open jobs in Brazil, but the search form isn't working 100% - search buttons throws a Javascript error.  Good news for my employer: no jobs posted for Brazil. This means that either there are no jobs available in Brazil or that SAP Brasil isn't pushing the adoption of the Career center. I opt for the last. As I'm more interessted in the global demand, I searched for all job postings that are related to portal.

What I have observed from looking at the posted job offers:

  • ESS/MSS is, together with BI, one of the most used Portal usages
  • We get Safari support because Apple is using SAP Portal
  • Many companies are searching architects
  • There are a lot positions open for developers (WebDynpro Java too)
  • Most companies don't understand what they are searching. 10 years of SAP Portal experience? More generic text about the company than about the job.

What does this mean for someone that is a Portal consultant?

  • You need to know Java, VC and WebDynpro and how to integrate them
  • Knowing only portal is not enough. You need to know how to integrate other product like: ESS/MSS, BI, MDM, SRM.
  • This implies that you have a good understanding of SSO, Security, Web (2.0), ESA / WebServices / Rest, Functional and technical aspects of the portal + business package and several SAP solutions that can be accessed by web, basic understanding of ABAP and ERP, UI and UX, follow newest trends like mobile.
  • Mobile Portal is nothing companies are searching. My guess is that they don't know that it is a really good idea to use the SAP Portal for mobile SAP access. Hope that this will change.

Does participation in SCN increases your chances to get hired?

Having a permanent work visa is a requisite for the jobs posted for USA. I could work in Europe, but the number of portal jobs posted for Europe is nothing compared to USA. I don't have a visa for USA, the country flag in my business card is set to Brazil, so I don't know if active SCN contributors in the portal area from USA get job offers. I guess that when a company posts a job offering they don't get a list of possible matches from the SCN community presented. That way they could pre-check some users to find out if they fit their need and, more importantly, check their contributions done to know if they have the right knowledge.

  BTW: saw a job posting from IBM, Honolulu. Would move to Hawaii today.

Tobias Hofmann

Mobile apps or HTML?

Posted by Tobias Hofmann Dec 8, 2010

Recently there has been a series of blogs about developing mobile applications using HTML5:

You cannot ignore it: mobile access to SAP is a hot topic. As there are also series of blogs focused on mobile business using Sybase and almost all news around SAP and mobile involve somehow Sybase, it's interessting to see what customer are using. At TechED Las Vegas I had the chance to attend some lectures about mobile applications running on BSP and SAP Portal. The Demo Jam winners demonstrated a HTML5 app. The question  now is: mobile access to SAP data by an app or HTML?


There are use cases where you need a local app installed on the device. MAM is a good example:

  • you'll need a local database
  • long offline time
  • complex data to be modified and
  • to be synchronized
  • background sync

Drawbacks from using apps:

  • Distributing apps is a challange, updating them too.
  • Sensitive data stored on the device; ensure security of data.
  • SAP MI, Gateway, Sybase or 3rd party mobile software bring their own infrastructure that needs to be integrated into the current landscape
  • Mobile policies change. Now the users are using Blackberry, soon  some will switch to an iPhone, Android or WM7 phone. And you'll have to  develop a version of your app for that device. Project  Gateway promises to ease this work.
  • An app for iPhone works on iPhone, but not an Android, BB or WM phone.


  • simpler use cases, no RFID, tag scanner or other special device hardware needed
  • online & offline
  • local storage of data
  • can be used by mobile and standard browser (1 application for all)
  • use of mobile device features like GPS

The usual offline access mode that demands for a local app is obsolete: we are living  in an online world and being offline means that you are either offshore  or in a  plane (and that is also changing: on some planes wifi access is  already reality). The background sync from apps is sometimes not even  considered, as the user will get a notification by e-mail or initiates the activity as part of his daily routine (while beeing in the train, bus, traffic jam,). Another point to consider HTML(5) is the experience available for high number  of concurrent user access to your web server.

The maiority of use cases is online consumption of data, the interaction  sometimes is only that the user is hitting the "approved" button or to  look simple data up like the phone or e-mail adress. To consume employee  data you may use a local app (+db) and store the contact data on the  device, but you cannot store all the employee data - at least when your  company has more than 1000 employees - or company policy don't allows  it. As this data is changing, doing a sync is mandatory; you don't  want to have an outdated phone number when you need it. A feature that counts more than offline storage of these data is to asve the contact data into the devices PIM.

Considering the number of concurrent users: while I attended the  lectures at TechEd LV I left with the impression that most mobile SAP  applications are made for a small number of users. 50 users already was considered high;  and that a really big issue is the sync of the data (users of MI may  remember the DOE sync issues). Looking at the usual "simple" use cases of  mobile applications, HTML(5) is the right choice: independently whether  you are using BSP or the Portal, you already have the knowledge of a  high number of users accessing SAP data. There won't be surprises when  >50 users are accessing the application at the same time.

The technolgies available and from what I've seen at TechED is what the customers are using for their development are:

  • BSP
  • Java (NetWeaver AS Java and SAP Portal)

The problem I see in developing HTML5 apps with SAP is that  there is a gap in the solution offering from SAP: there is no offering from SAP.  If you want to develop such a HTML5 application, you'll have to do it by yourself. And mobile browsers are not really supported (Service Market  Place: PAM).

Do you want to use BSP or AS Java or the SAP Portal? Of course I only can recommended using the SAP Portal. It offers:

  • Profiles
  • Filter content based on URL (Filter ID)
  • Made for browser access
  • System landscape with SSO to backend systems
  • Caches
  • Portal services

With profiles, roles and filter ID the portal filters the navigation. Instead of having 20 apps for ESS and MSS on the home screen, the users may only have 2: ESS and MSS that open the navigation of the area in the portal depending on the associated roles of the user. With SSO, it is also possible to easily integrate other web content (ex.: ITSmobile transactions). The HTML application can reuse interfaces already in use: Web Services  and JCo/JCA/BAPI from WebDynpro applications. The same HTML5 application can be used by mobile and desktop access. No need to develop the same application several times. Once logged in the portal, the end-user can make use of the portal services like UWL, favorites, KM (download documentation), or other APIs available.

PMC235: Petrobras: SAP NetWeaver Portal as an Application Portal

On tuesday, October 19 I will present the 1h educational session PMC235: Petrobras: SAP NetWeaver Portal as an Application Portal (4:30 p.m.–5:30 p.m.). Petrobras is using the SAP Portal as an internal portal for accessing SAP data over the web. These applications span a wide range of use cases: from financial to HR applications. The portal itself is used by more than 60.000 users throughout Brazil.

I will present how and why we customized the portal to achieve:

  • High user satisfaction
  • Single Sign-on from the browser to the backend
  • Integration and access to backend data (WDJ/A, VC, BSP, Java)
  • Corporate design
  • Custom iViews (with support for several browsers)
  • Significant performance enhancements
  • Transparent user actions by analyzing access data
  • Maintenance and infrastructure

To conclude this blog a short outlook: Mobile SAP Portal


Filter Blog

By date:
By tag: