Tuesday 4 March 2014

Introducing the Yeoman Generator for OpenUI5

Myself and Sascha Kiefer have created a Yeoman Generator for OpenUI5 / SAPUI5.

See our SCN blog post for all the details; and get coding UI5 apps with automatic generation of all the boilerplate!

Wednesday 7 March 2012

Testing email in SAP systems

Sometimes you just want to test if email is working properly in your SAP system. For example the Basis guys have just built a new box... Typically they forget to configure SAPconnect appropriately...

You can simply run ABAP program: RSBCS_EXAMPLE_EMAIL. This will allow you to test out all the standard email functionality. Internally it uses the BCS classes (Business Communication Service). You can run this program directly from transaction SE38.



When you see the following result... You know that SAPconnect is not properly configured.
Time to talk to your basis consultant.



What about SAP Business Workflow and external emails?

External emails are emails sent through your companies exchange server to an internet email address. When addressing an email you can use address type "U" for internet email and an email address: test.user@test.com.

But... When working with SAP Business Workflow it is common to use type G addressing which is where you can specify a HR object(s) as an email recipient.

For example, the standard Workflow Send Mail step allows you to bind a a list of HR objects as recipients which his commonly done by using an address like this: "USSAPUSER". Where US specifies the object type as a User Id and SAPUSER is the actual system userid of the person. This value is availble in the USR01 BOR Object which is handy.

The problem is that often when a Basis Consultant installs a system and enables smtp with SAPconnect they forget to do the additional config to enable this "type G" email addressing. So here is what you need to do...

Goto transaction SO16 (Shared Office Settings) and enable "Send to Home Address of Users".


Now check the User Id's - they need to have the Communication Method set "E-Mail" (and an email address of course!).


And thats that! You can now drop email steps into your Workflows and have them work with the standard HR Object based addressing.

Wednesday 15 February 2012

SAP Flight Bookings Data Model - where is the data

As a developer, when you get access to a brand new sap system, the first thing you want to do is to test out some of the new features with some test apps.
I've just started at a new customer site with lots of new goodies - such as NetWeaver 7.30 systems.
To test out some of the new features in WebDynpro for ABAP  (and the look & feel) I wanted to write a couple of test apps.
What data should I use? Its a brand new system so there isn't much.
This is where you often rely on the good old Flight data model which SAP provides just for this purpose - learning and testing.

Problem. The flght data model tables (such as SFLIGHT) are all empty.

Solution: Run the program: SAPBC_DATA_GENERATOR in SE38.



This program will populate the entire flight data model for you based on a few simple selection criteria (you would typpically leave the default settings).
You can now use SE16 to confirm that the flight tables have been populated...

Saturday 21 January 2012

Get Ruby up and running on your Mac

As part of my mission to learn the Ruby language, I've had to setup my Mac for development. These are the steps I had to go through to get the latest version (1.9.3-p0) of Ruby up and running on my Mac. I've just gathered the info from other blogs and websites and put it together here into a simple list of steps. Note that this is just one of many ways of getting Ruby up and running on your machine. In fact a Mac already comes with Ruby pre-installed - but it'll be an older version - 1.8.7 is what I had with Lion.


Writing apps with Ruby requires so little code its amazing. Combining it with the Sinatra gem makes it ideal for writing RESTful backends for apps. We'll leave this bit for another blog.  ;-)



Warning: some of the steps below download and execute remote scripts on your machine. This is generally something to be very careful of. Please note in the cases below that these are valid and trustworthy scripts. The source code can be viewed before you execute them with the hyperlinks I've included.


STEP 1: Install Apples Xcode developer toolset (if you haven't already)

We need Xcode for the c compilers which are used to build and install the tools to follow. Open up the MacAppStore and search for Xcode, then install. This will take a while...

Once installed; for some reason... the following install steps failed at on the compile of rvm. You may not have this issue, but just in case, lets build a dummy Xcode project. This will ensure everything goes smoothly later on.

Just open Xcode and start a new Project. Select Mac OSX and Cocoa Application. Let it auto-setup the project for you. You've just got to provide a name and a location for your project. Don't bother with source control. We are only doing this just to run the compiler.

You should now see something like this:


Next select Product -> Build which will compile your dummy Mac OSX application; then Run (if you want to see an empty application). Thats it now - go on with the next steps...


STEP 2: Install Homebrew

Homebrew is "The missing package manager for OSX".

Open up Terminal and enter the following command to install it:

/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"


This actually downloads a remote script (run program) which is executed to download, build and install Homebrew. You can see the script here. Installs Homebrew to /usr/local so you don't need sudo to 'new install'.


STEP 3: Install Git

Git is a source control and version manager program. It is used absolutely everywhere by the open source community. You can use it to manage source code (or any files for that matter) repositories on your local machine, between remote machines or more commonly with a source code repository such as GitHub.

Open up Terminal again and type the following, which will ask Homebrew to go and get Git and install it on your local machine.

brew install git

At this point you can use Homebrew to install all sorts of other tools (however I skipped this for now). For example to install MySQL use:

brew install mysql



STEP 4: Install rvm

rvm is the Ruby Version Manager. It lets you easily switch between different installed versions of Ruby. Here's a blurb from the rvm site:

"Wondering why you should use RVM? For a start, not only does RVM make installing multiple ruby interpreters / runtimes easy and consistent, it provides features such as gemsets that aren't typically supported out of the box on most ruby installs.
RVM also lets you use different rubies in a manner that wont mess with your existing ruby install (unless you tell it to) as well as letting you run multiple different rubies in seperate terminals concurrently!"


Enter the following command to download a script which will install fetch and install the latest version of rvm. See the scripts source code here if you like.


bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)



You can also add the following to the end of your bash_profile (~/.bash_profile) which makes it easier to work with rvm at the command line. I didn't have to do this as it was already in there - maybe due to an updated installer script.


export PATH="./bin:$PATH" 
[[ -s "/Users/jason/.rvm/scripts/rvm" ]] && source "/Users/jason/.rvm/scripts/rvm"


You can now tell rvm to use this bash environment with:


source ~/.bash_profile




STEP 5: Install the latest publicly available version of Ruby

Tell rvm to install the latest vernon of Ruby with this command line:

rvm install 1.9.3-p0 --with-gcc=clang


The --with-gcc=clang is necessary if you're running Xcode 4.2 or newer. Without it you'll receive errors similar to this:


Error running ' ./configure --prefix=/Users/jason/.rvm/rubies/ruby-1.9.3-p0 --enable-shared --disable-install-doc --with-libyaml --with-opt-dir=/Users/jason/.rvm/usr ', please read /Users/jason/.rvm/log/ruby-1.9.3-p0/configure.log
There has been an error while running configure. Halting the installation.



This will take a little while to run while Ruby is downloaded and compiled and you'll see the following output:


Fetching yaml-0.1.4.tar.gz to /Users/jason/.rvm/archives
Extracting yaml-0.1.4.tar.gz to /Users/jason/.rvm/src
Configuring yaml in /Users/jason/.rvm/src/yaml-0.1.4.
Compiling yaml in /Users/jason/.rvm/src/yaml-0.1.4.
Installing yaml to /Users/jason/.rvm/usr
Installing Ruby from source to: /Users/jason/.rvm/rubies/ruby-1.9.3-p0, this may take a while depending on your cpu(s)...


ruby-1.9.3-p0 - #fetching 
ruby-1.9.3-p0 - #extracted to /Users/jason/.rvm/src/ruby-1.9.3-p0 (already extracted)
ruby-1.9.3-p0 - #configuring 
ruby-1.9.3-p0 - #compiling 
ruby-1.9.3-p0 - #installing 
Retrieving rubygems-1.8.15
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  245k  100  245k    0     0   105k      0  0:00:02  0:00:02 --:--:--  148k
Extracting rubygems-1.8.15 ...
Removing old Rubygems files...
Installing rubygems-1.8.15 for ruby-1.9.3-p0 ...
Installation of rubygems completed successfully.
ruby-1.9.3-p0 - adjusting #shebangs for (gem irb erb ri rdoc testrb rake).
ruby-1.9.3-p0 - #importing default gemsets (/Users/jason/.rvm/gemsets/)
Install of ruby-1.9.3-p0 - #complete 



Great! Now we have the latest version of Runy ready to go. We just need one more thing to tell rvm to always use this latest version as the default so run this at the command line:


rvm use 1.9.3-p0 --default



Just to check that you do have the latest version and everything has gone just write enter:

ruby -v

and you should see

ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0]



Now start coding...

Wednesday 18 January 2012

SAP's mobile apps strategy - a discussion


What is needed to write apps in SAP's mobile architecture?


There seems to be allot of options and developers that I speak with are rather confused, so here is an overvierw of the offerings based on my recent research:

  • SUP (Sybase Unwired Platform). SUP enables you to build mobile apps (both native and with the hybrid web container) which can connect into your SAP backend systems via MBO's (Mobile Business Objects). MBO's can be developed within Eclipse and can cater for data caching and synchronisation. It provides for secure channels between SAP and the device.
    SUP needs a server insisde the corporate network.
  • Relay Server or any other proficient reverse-proxy tool that can sit in the DMZ if you're going to use external mobile devices (and who wouldn't).

The above will enable you to build apps that allow mobile devices to access SAP backend data, synchronisation (for offline use), notifications and security. But not enough to run most of the SAP-developed apps already on the SAP app store.
(Check out John Moy's SDN blog which includes a great analysis of the system requirements for each app in a matrix.)


Now as additional elements it seems we have:
  • SAP Netweaver Gateway. Essentially an abap add-on product so it needs an abap stack (See all recent twitter discussion on that. My thoughts are it should be just part of standard abap runtime like web-services are). This would enable your mobile applications to access data via the OData (RESTful-like) protocol and is another avenue into the SAP backend system without using SUP's MBO's. (Why would you use one over the other I wonder? Please comment below. SAP look to be positioning the use of Gateway for "online" apps and MBO's for apps that can work offline: see recent SDN blog by David Thirakul from SAP.)
    Something to note is that the OData client API's are currently only provided by SAP in native code, which rules out using web technologies like html5, jQuery Mobile, etc (or even SUP's hybrid web container) for the client app.
  • Data Orchestration Engine (DOE. Seems to have previously gone by the name of SAP MI - Mobile Infrastructure). This looks to be another abap stack based toolset that provides some sort of wrappers around SAP BAPI's, enabling access from a mobile device via SUP.
  • More... There are possibly more options as well. There is the "Portal on Device" initiative, which enables the SAP Portal to serve up html5 and jQuery based pages to mobile devices. (Personally, I think the Portal is very bloated however and complex to manage.)

Each and every one of the above requires a server somewhere. Each and every one of the above has licencing costs, infrastructure costs, maintenance costs and knowledge costs (staff need to learn).
Imagine when you add in the typical 3-tier landscape!!!

The SAP clients that I have knowledge of, already seem to be weighed down by the sheer weight of servers everywhere.

From looking at the SAP App Store most of the mobile apps require both SUP 2.0 and Netweaver Gateway 2.0 as minimum requirements. It just seems like a very complex and confusing setup to me. Something that could be far easier... And I haven't mentioned the Afaria (or another vendors') device management tool, which would mean another server(s) to look after.

Maybe if all of the above was enabled as a PaaS offering (hint hint).  PaaS (or Platform as a Service) being the situation where the hardware and system is hosted in the cloud and clients can use it to develop their own mobile solutions.


With mobile device development something that I have a keen interest in, I've been investigating the alternative approaches to development of apps. Using HTML5 and frameworks like jQuery Mobile it is relatively easy to build mobile cross-platform apps. They can be "native" as well by using the web container approach (i.e. PhoneGap - which SAP are kind of replicating with the SUP Hybrid Web Container).
As other community members have shown in recent blogs its also possible to easily use the ICF built into every Netweaver ABAP stack to serve data in a RESTful manner to these mobile apps.

Is this the easier route? Are there security implications? You would still use a reverse-proxy setup to enable devices outside the corporate network to access data. SSL etc. Devices can still be locked, tracked or remote wiped.
What about "offline" scenarios. SUP does provide for this in a secure fashion but it can also be done with HTML5 and javascript if necessary and their are jQuery frameworks already becoming available to do this (i.e. jquery-offline).

So... which way is better? Will SAP clients jump onto the SUP and Gateway bandwagon (and Afaria)? At this stage what I can imagine is a situation where clients take the easier option of using open source frameworks for their mobile app development to "test the water"; maybe even with Gateway. If they decide upon a full-blown mobile rollout at large scales, then I'm sure they will go with the SAP recommended solution of SUP & Gateway... but this is probably a few years away...

Lets hope for the following in 2012:

  1. Change the SUP/Gateway pricing model to remove the barriers for clients to get onboard.
  2. Enable access to SAP for the development community and not just large SAP partners (for FREE!)
  3. Please look at a PaaS offering to ease the server burden.

Thursday 12 January 2012

Sample mobile app created in the cloud

For my first test mobile app I've used Tiggr which is a cloud based development tool which uses jQuery Mobile under the hood. You can drag and drop screen elements, add event handlers and add sections of your own script as well. It also includes a data mapping tool to easily integrate RESTful services into your app. It's a great tool especially if you're new to mobile development like me or you wish to whip up something quick - maybe for prototyping.

My sample app (shown below) is very simply as you can see... One input field and a button. When clicked it stores the contents of the input field using html5 local storage and then navigates to the second page, which in-turn reads the value from local storage and displays it in a label element. (Gotta start somewhere!)

Initial screen
Saved in HTML5 local storage

Tiggr development does have a cost.... $45 per month but the first month is free. (Note: see comment below about free plans.) After speaking with the developers you can enable and disable your account whenever you like to avoid continually being charged. Your files will be removed however. To avoid losing anything just export your project so that you get to keep all the source files. They are thinking of enabling an archive mode so that you can stop using the service but all files are kept in archive for when you're ready to start developing again.

Speaking of the developers - I can say that their support is good and I haven't had to wait more than a couple of hours for a response to questions.

Main development screen

Next step is to sign up as an Apple Developer so I can test out PhoneGap and turn this into a native app (in reality I'll probably build something a little more substantial). You need to be signed up as an Apple Developer to get the necessary security and provisioning keys so that you can actually build an iOS app. I'm also busy learning about Ruby and Sinatra for building backend RESTful services, but I'll leave that for another blog post...




UPDATE: 18 Jan 2012
Tiggr have changed their name to Tiggzi and updated their plans (including a free one):




Also check out an overview of Tiggzi's features for building apps.

Sunday 8 January 2012

My first ever blog post

Hello. This is my first blog post. I'll update this blog regularly with news, tips and my thoughts in the SAP technology areas particularly related to ABAP, Mobile Devices, Netweaver PI / BPM, Workflow and HANA.


To start off with I'd like to recommend a good introductory book into mobile device programming with jQueryMobile:
Master Mobile Web Apps with jQuery Mobile (Second Edition) by Matt Doyle.


jQuery Mobile is a javascript and HTML5 based framework for developing cross-platform mobile device apps (for iPhone, Android, etc).
Apps can be wrapped up inside a web container to turn them into native apps for each device with PhoneGap.


There will be much more to come on this subject as I post about building my first couple of mobile apps...