florian.mueller2

SAP Glossary availbale within App Store

Florian Mueller — Wed, 19 Jan 2011 02:45:49 GMT

SAP buzzword glossary released as iPhone App

During one of our technology evaluations we have created a SAP Glossary iPhone application containing several "SAP buzzwords" and corresponding explanations - nothing big but maybe useful for sales guys catching up some buzzwords during lunch and looking these up directly instead of talking about unknown technology...
If you want to provide additional content feel free to contact us, we are willing to extend contents, feedback is taken seriously!

You can download the application within the App Store, it's called "Resource Sales Glossar"

(iTunes Link)

Currently the glossary is base on German language we are planing to provide an English version as as soon as possible...

Cheers, Florian!

Creating mobile apps on top of SAP - Part2

Florian Mueller — Sun, 02 Jan 2011 16:24:01 GMT

Outlook

Welcome to the second part of our mobile
SAP tutorial! Let's quickly sum up the overall goal which is creating so called
"instant value mobile applications" in terms of lightweight mobile
solutions which do not require a fully blown Sybase stack - of course the
Sybase stack can not be replaced based on this simple stack, but as already
mentioned, there might be requirements which could be solved in a more
efficient manner using a lightweight approach...

In the first part of this tutorial series
we chalked out how to expose a SAP BAPI as a Web Service. We used the common
known FLIGHT BAPI so at the current state of the tutorial we have a Web Service
up and running providing a simple method called "Flight Get List". If
you should have missed the first part of the tutorial, here's a link to the
first part:

[http://www.resource.ch/userfiles/medien/blog/SAP_mobile01.pdf | http://www.resource.ch/userfiles/medien/blog/SAP_mobile01.pdf]

Please
notice as well: if you should have a different Web Service instead of FLIGHT
BAPI, no matter, the following steps apply to any SAP Web Service - it's
completely up to you whether you wanna show up some flights or some CRM data on
your mobile device.

h3. 1 Sum
Up

Ok, last tutorial has been released couple
of weeks before this part, so we will start with a quick sum up in order to get
you up to date on what has been achieved as well as what will be achieved
today. As already mentioned, we have a simple Web Service up and running
providing SAP related data based on several input parameters. This is always
kind of basic step before you actually start thinking about the client layout,
technology etc.; as already mentioned, you can use any Web Service from your
SAP system and do not require our FLIGHT BAPI Web Service.

We suggest, you use SOAPUI and test your
Web Service before you continue with our implementation, at this state you
should have an accessible Web Service which returns some data from your SAP
system when executing a dry run within the SOAPUI environment (SOAPUI is free
of charge and can be downloaded here: http://www.soapui.org/). Our Web Service
for example returns 15 flights when passing in the "LH" (Lufthansa)
carrier, see screenshot below:

!http://www.richability.com/resources/tmp/pic02.png|alt=|src=http://www.richability.com/resources/tmp/pic02.png!

Ok, so this should have been achieved after
the last part of the tutorial so let's switch to the next chapter and see what
we will achieve within this second part of the tutorial.

h3. 2 Outlook - what we will achieve

Please remind the big picture (see below) -
the grey box is up and running for now so let's focus the blue box above: on
the one hand the blue box provides UI stuff to our mobile client (this is NOT
covered within this 2nd tutorial part), on the other hand the blue box connects
the Web Service - which is what we will do today. It is important to connect
the Web Services using Java language as the client interface (vaadin) will be
created based on Java as well - so if we have the Web Services accessible
through Java we can easily use these within our mobile client.

The Web Services will be connected via
Apache Axis 2 - the cool thing about Axis: Axis will translate the WSDL to Java
classes automatically so all you need to know is how to invoke Axis on your Web
Service. After generation there will be a Java stack available enabling you to
access your Web Services easily.

!http://www.richability.com/resources/tmp/pic03.png|height=650|alt=|width=650|src=http://www.richability.com/resources/tmp/pic03.png!

h3. 2.1 Requirements/installations

In order to
generate the Java stubs on top of your Web Service (as well as for the vaadin
UI creation in the next part of the tutorial), you require several tools:

Eclipse IDE for Java EE developers (3.6): http://www.eclipse.org/downloads/ (!!! MAKE SURE YOU CHOSE THE "IDE FOR JAVA EE DEVELOPERS" !!!!)

Apache Axis
(2.1.5.2): http://axis.apache.org/axis2/java/core/

Download Eclipse
IDE as well as Apache Axis, next fire up Eclipse and your are close to implementing/generating
the Web Service stubs.

You can create a new workspace (Eclipse will ask you when launching first time), just give it a name such as myMobileSapWorkspace and wait until Eclipse finished loading. There is one important configuration issue which needs to be achieved in order to run Axis2 as Eclipse by default ships with the old Axis1 - using the old Axis would work as well but as there have been huge changes from Axis1 to Axis2 you should link in Axis2:HttpTransportProperties.Authenticator
+ auth = new HttpTransportProperties.Authenticator();<br /> auth.setUsername("username");<br /> auth.setPassword("*******");+

_operationClient.getOptions().setProperty(org.apache.axis2.transport.http.HTTPConstants.AUTHENTICATE, auth);

4) here's what the whole block should look
like;

...

try{

+ org.apache.axis2.client.OperationClient _operationClient = serviceClient.createClient(operations[0].getName());+

+
HttpTransportProperties.Authenticator+

+
auth = new HttpTransportProperties.Authenticator();+

+ auth.setUsername("username");+

+
auth.setPassword("********");+

+
_operationClient.getOptions().setProperty(org.apache.axis2.transport.http.HTTPConstants.AUTHENTICATE, auth);+

+ operationClient.getOptions().setAction("urn:sap-com:document:sap:soap:functions:mc-style:zget_flight_list:ZFlightGetlistRequest");+

+
_operationClient.getOptions().setExceptionToBeThrownOnSOAPFault(true);+

...

This adds security credentials to the
request before the request is actually being send to the Web Service, if you
have no security on top of your Web Service you can skip this step.

h3. 3.1 Using Java Web Service Stub

Ok, the whole Web Service stub is ready for
usage right now - which means, we can create a very simple demo app (simply add
new Class to your src directoy), the class could look like this:

public class TestService

{

+ public static void main(String[] args)+

throws Exception

+ {+

+ onSearch("FRANKFURT", "TOKYO");+

+ }+

+ private static void onSearch(String fromCity,String toCity)+

throws Exception

+ {+

+ Z_get_flight_listStub stub = new Z_get_flight_listStub();+

+ Z_get_flight_listStub.ZFlightGetlist
request = *new *Z_get_flight_listStub.ZFlightGetlist();+

+ // from+

+ Char20 from = new Char20();+

+ from.setChar20(fromCity);+

+ request.setImwCityFrom(from);+

+ // to+

+ Char20 to = new Char20();+

+ to.setChar20(toCity);+

+ request.setImwCityTo(to);+

+ // fire request+

+ final Z_get_flight_listStub.ZFlightGetlistResponse resp = stub.zFlightGetlist(request);+

+ // extract
results...+

+ int numberOfItems = resp.getExtFlights().getItem().length;+

+ System.out.println("Found flights: " numberOfItems);

+ }+

}

You are done! Test the service by simply
running this class - in our case the service returns 15 flights from Frankfurt
to Tokyo which have been looked up within the SAP system.

Let's sum up what we are doing within this
class:

1) Instantiate sup and create request on
top of stub:

+Z_get_flight_listStub stub = new Z_get_flight_listStub();+

Z_get_flight_listStub.ZFlightGetlist request = *new *Z_get_flight_listStub.ZFlightGetlist();

2) Use the generated datatype classes and
populate these - datatype classes? you might wonder...Axis is pretty clever -
Axis checks automatically the datatypes required by your Web Service and
creates datatype classes - this ensures you do ot push String longer than
expected/allowed to the Web Service, it's a nice and efficient manner to
prevent you from checking "what dataytpe and which length is expected at
the service...?". (Char20 means datatype Char, maxlength 20)

// from

Char20 from = new Char20();

from.setChar20(fromCity);

request.setImwCityFrom(from);

// to

Char20 to = new Char20();

to.setChar20(toCity);

request.setImwCityTo(to);

3) fire request and process results...:

// fire request

+final Z_get_flight_listStub.ZFlightGetlistResponse resp = stub.zFlightGetlist(request);+

// extract results...

int numberOfItems = resp.getExtFlights().getItem().length;

4) done! you just accessed you SAP Web Service
through a Java Axis layer, this Axis layer now can connect to any Java related
mobile UI technology - which is great and enables us to create a nice vaadin
iPhone UI on top of this stub within the next tutorial...!

h3. 4 Next
steps

The next tutorial will get you in touch
with development of mobile UI based on vaadin. As vaadin is plain Java there
will be no difficulties to connect the stubs created within this tutorial part.
Basically the "boiler plate stuff" is done at this point of the
tutorial, next thing is the really exciting (and funny!) part , which is
creating the iPhone UI...!

"App" or "Application" development

Florian Mueller — Mon, 06 Dec 2010 09:25:33 GMT

"App" or "Application" development?

"mobile apps are in!", there is no doubt regarding this statement - everybody is mobile, you cant even walk down a street without passing some guys focusing concentrated on their mobile devices. So there seems to be a huge target audience to mobile solutions, the question is just whether there is a need as well...as I neither want to follow the philosophic track within this article nor want to get into the "Gartner track" such as "we have analyzed that 79,3% of 30% of all people aged between 24 and 32...." I will simply come up with some common thoughts and results we discovered while we took our first steps entering the mobile SAP market and would like to share these common thoughts.

Let's focus on technical aspects of mobile SAP applications first before we switch to business related thoughts. As you might know there are several tools and frameworks around which enable you to "mobilize" your SAP system, on top of these the powerful Sybase flagship. Basically the Sybase approach enables you to focus entirely on business aspects of your application, we will not get into details of Sybase platform within this article but chalk out the major benefits of using Sybase Unwirde Platform: Sybase provides a powerful IDE, the IDE can be used for UI creation as well as UI wiring to BAPIs/Web Service/database etc. - all based on drag & drop without writing a single line of code. But Sybase is much more than mobile application development "only", Sybase provides a full stack of enterprise related features such as app distribution, device management, offline scenarios, security etc.. Previously listed features are exactly the major difference between "App" and "Application" devlopment, as Applications should provide the following features (besides the core business aspects):

security (a web service being access from within a DMZ always needs to be secured!)
offline capabilities (what if the network goes down while entering data? Re-entering data is not an option...!)
device management (manager has different data view than employee)
automatic distribution(manager does not want to browse the App-Store)

If you do not require these features you can head for "App" development which is in nothing but exposing BAPIs to Web Services and accessing these Web Services through native mobile clients (iPhone/Android/Symbian etc.). Exposing BAPIs to Web Services is a default feature available within any SAP system so the workload is shifted to client development.

So when to chose "App" development and when to head rather for "Application" development? Is there kind of checklist which could be used chalking out whether an App or an Application is required? Unfortunately there is not but there is an easy path which could be followed, Resource AG uses this path for a couple of months and we would like to share our experinces right here: Chosing Sybase as implementation framework usually results in licence fees and a very huge consulting project as Sybase Unwried Platform is nothing which simply gets installed and configured, creating your application based on Sybase Unwired Platform will result in a project > 6 months, therefore you will benefit from all features listed above.

So customers need to think well about this decision, there is always big danger of using a sledgehammer in order to crack a nut - on the other hand there is a lightweight approach which results in client development only and could be used after couple of days iPhone/Andorid client development, so customers as well as consultants are facing the issue of over/undersizing cutomer requirements. That's exactly the point which is misunderstood as there is no decsion such as "either or", it's much more about following both tracks: customers should never start implementing based on Sybase Unwired Platform directly: usually requirements for mobile applications are pretty foggy as there is not much experience within this topic (compare to Java apps: did you ever join/launch a Java project without requirements changing during project implementation? I guess ou never will, even Java is very etsablished and well known...).

So the first thing you should always do is creation of prototypes mirroring the requirements of your application. You can do these prototypes based on the lightweight approach as this approach enables you to create results instantly and provide thes to your customers/employees. Next you can figure on aspects such as offline capabilities and figure out whether you really need these: it's much easier to decide about this based on a running prototype which can be passed to a field service engineer in order to determine whether he is actually facinf offline situations or whether these never occur and in consequence should not be implemented. If so, you can follow the lightweight approach, if not you should switch to the Sybase track: your benefit from switching at this point is that your screens can be reused! Sybase (currently!) does not provide iPhone client development which means you have to create the client on your own within the XCode development IDE - so this step is required for "App" as well as "Application" development so there is no need to wire this step to Sybase / lightweight development; but as setup of a complex Sybase landscap takes time and experience you should simply start creating an application without any Sybase technology and switch to the Sybase track as soon as you are facing a need which can not be covered following the lightweight approach. Several Resource AG customers noticed during development following the lightweight approach that this approach would cover and adress all of their requirements, others noticed they would require Sybase for several reasons, but you should never decide about the technology (Sybase or custom?) directly without creating a lightweight prototype! Chosing Sybase as this is what SAP recommends and pushes is not an option, you should always decide based on a technology base instead of marketing papers which results in the followin decision steps:

create a prototype based on core Web Services and native client development
check whether you really require sophisticated features by testing the prototype
decide about technology (custom or Sybase)
start implementation...

We recommend these steps to any customer or conulting company, if you should have further questions on our prototype concept dont hesitate and get in touch with us directly, info@resource.ch or Florian.Mueller@resource.ch.

Cheers, Florian!

Creating mobile apps on top of SAP - Part1

Florian Mueller — Tue, 23 Nov 2010 07:08:21 GMT

As you might have noticed there is happening a lot within the space of mobile application development. Focusing on SAP applications and tooling there is Sybase on the one hand, on the other hand there is SAP Netweaver mobile platform, both frameworks apply to what we gently call „heavy frameworks“ – be assured you need several consultants and SAP trainings in order to establish this landscape within your company or your customer’s environment...

But there is another approach as well – it is not hyped the way Sybase is currently celebrated but for certain requirements applies much better than heading for a heavy approach. Of course you can use a sledge-hammer to crack a nut but there might be alternatives around.

During this series of tutorials we will come up with several ways of implementing mobile frontends for your SAP system. As we know that it is not on everybody’s agenda to buy a Macbook before we actually start creating iPhone/iPad user interfaces we will show ways of using powerful HTML5 frameworks which result in 100% iPhone/iPad look and feel, have a look at the following screen, this is what based on HTML5 can be achieved:

But dont be afraid – you do not need any HTML5 knowledge, all we will do is coding plain Java and trigger several Web Services. Btw., the same applies to Android applications we will show you ways of creating Android clients within minutes instead of becoming Android expert before you actually start your first application. And of course, in oft the last parts of our tutorial we will show you how to create native iPhone/Android apps.

You simply should keep in mind: this tutorial gives chance to anybody to create so called „instant value“ mobile apps – which path you follow is completely up to you and your requirements!

Tutorial Structure

1. „Boilerplate“: covers creation of backend web services within your ERP (covered within this document)

15/11/2010, Contact/Feedback: Pascal.Moser@resource.ch

2. „Eclipse Connect“: Eclipse IDE will be used as major development IDE. Before we actually hook the web service into a „real“ mobile client we will create all necessary Java stubs in order to access the SAP Web Services

25/11/2010, Contact/Feedback: Florian.Mueller@richability.com

3. „SAP iPhone handshake“: we will use the vaadin framework within the Eclipse IDE and create the mobile client which consumes the previously created Web Services

01/12/2010, Contact/Feedback: Florian.Mueller@richability.com

4. „SAP Android handshake“: creation of mobile Android client (based on Adobe AIR) accessing SAP Web Services previously created

release date follows...

5. „SAP native iPhone“: we will create a native iPhone client (Mac + XCode IDE required) accessing our SAP Web Service

release date follows...

Requirements

Each tutorial requires certain skills, software and hardware so we will create a brief list of requirements within the head of each tutorial. Please dont be afraid in terms of „I will fail as I have no clue on iPhone development...“, you do not need to know anything about mobile application development as we will show you during these tutorials!

Anyway, there are major requirements which should be met, you need to be familar (basic knowledge) with:

• ABAP basics („know how to fire up se80...“)

• Basic understanding of Web Services (SOAP)

• Basic Java knowledge

In order to follow this tutorial you will require:

• SAP ERP 6.0

• Netweaver >= 7.10

Any additional software you will require is explained within the tutorial such as Eclipse, SOAP UI etc..

The BIG PICTURE

Before we start the creation of SAP Web Service boiler plate we will give you some information on what we will be implementing and we will chalk out the very big picture of what we would call the architecture behind the application.

The Scenario

People told me (as I’m from the „Java world“ and did not go through all these SAP classes) that „FLIGHT BAPI“ is something similar to what Java guys call „Hello World“ in terms of everybody knows these BAPIS and everybody has these BAPIS around on his ERP system somewhere. So we will use these BAPIS and put a Web Service interface above these so you can access these BAPIS through the Web Service.

From the SAP point of view we are done as soon as these BAPIS can be access through a Web Service, of course you can turn/cover any BAPI into a Web Service and that is exactly the idea of showing you how to do so: you will be able to publish any BAPI you want as a Web Service and of course you will be able to put a nice mobile UI on top of your Web Service – so you FLIGHT BAPI as starting point, as soon as you got the idea start applying your knowledge to customer projects...

We will do some simple calls based on these Web Services, we will trigger a flight search passing in departure as well as destination and our mobile device will display the query results:

The architecture behind

As already said we do not want to bother you with XCode development during the first parts of this tutorial – all UIs will be created based on alternative technologies such as HTML5. Please have a look into the following scribble, this sccribble chalks out the very big picture of what we will be implementing.

Within the current tutorial we will create everything which is grouped in the grey box at the bottom of this scribble. The blue box applies to what SAP calls Reverse Proxy, please do not focus on security aspects when working through the first parts of this tutorial series now – we will cover security aspects in a dedicated tutorial! We simply refer to the blue box as „Java client layer“, the blue box is used in first place for generation of HTML5 through frameworks such as vaadin & co...

No that you got the big picture it’s time to get the grey box working – so let’s roll up one’s sleeves and create some Web Services within our ERP!

............................................

Unfortunately using images within SAP blogs is pretty nasty and takes a lot of time - nothing you should care about, but reason enough for us to reference the article as a PDF doc, the PDF mirrors the whole part 1 of this tutorial, whole article is hosted at:

http://www.richability.com/resources/sap/SAP_mobile01.pdf