Background

This blog post started off as a comment reply to the very brilliant blog posted by John Moy - What SAPUI5 and Fiori tells us about the future of UI development skills - but as usual with my comments it quickly became long, rambling (a little boring?) and marginally ranty so I thought I’d give in and finally complete my first blog posting on SCN…  (As an aside, I’ve been threatening to blog on SCN for years & years and just never got round to it – customer work and life in general always get in the way.  I think I've made up for it here, in quantity if not quality!)

Following John’s posting, there was a short twitter conversation around the subject but I couldn’t do justice to my thoughts with only 140 characters at a time!

As mentioned on twitter, I completely agree with all of John’s comments and have been having many similar conversations recently with my colleagues and my manager.  I'm keen to encourage some of our ABAP experts to expand their skillset into Gateway at a minimum, as this in my opinion (and many more learned SAP people) is going to be a big part of the technology stack moving forward.  As it is an extension to the ABAP stack, I don't believe this is a massive leap either, which is a bonus.

More interesting is the change in UI tech (again!)  The big challenge for me is that SAP don't seem able to stick to a long term solution in this area (much the same as the rest of the IT industry) but do insist on inventing their own mechanisms, standards & frameworks for UI development time after time.

My UI History.

I started ~14 years ago as an ABAP developer and since then I've:

• As a noob, got outwitted by PAI and PBO modules, pf-status’ and related entities, and been thankful that I could move into more web based UI design, and stick to only building business logic in ABAP!
• Hated working with ITS which made no sense, was horrible to design & build with and delivered poor results.
• Got frustrated with the Portal API and its limitations, and how there was no real development environment with nice wizards and stuff 
• Grown to really like Web Dynpro Java, the development environment and most importantly, the power it gives me when combined with CAF, BPM & BRM, and more recently PI all wrapped up as PO.
• Grown to be really frustrated that Web Dynpro Java still delivers dull old grey & blue screens.
• Lost hours to frustration & anger working with Java Struts whilst implementing CRM Internet Sales 4.0 and the old Java based IPC.
• Enjoyed wrapping CE CAF delivered services in jQuery and SUP Hybrid web containers, and the quality UI experience this can deliver.
• Instantly got frustrated that Agentry appears to be displacing SUP and my skillset is out of date before I’ve even got my head around it.
• Got frustrated that every time I complete a Sybase mobile training course, SAP shift the goal posts and change the tech and roadmap (who knows how customers must feel?)
• Wondered why SAP had to invent HTMLB - what was wrong with HTML?!
• Wondered why SAP had to invent BSP - what was wrong with JSP, ASP, etc.?!
• Wondered why SAP had to invent SAPUI5 - what is wrong with pure HTML5?!

I'm sure if I was more awake (our 7 week old son isn't helping on that front!) I'd be able to remember other great UI odysseys of my SAP career...  I don’t even like talking about Visual Composer as it triggers night terrors.

The Point?

The key point is I've had to constantly learn and change my skillset, bouncing from ABAP, to HTML, to Java, to JavaScript, etc. which is great as I am motivated by and enjoy learning new technologies.  However, all of this makes it almost impossible to put longer term UI roadmaps in place with customers.  I'm currently losing the will to live with the constant changes to the SAP Mobile Platform.

I won’t even talk about the time and effort needed to keep up to date with all of the constantly changing SAP technologies – I’d love to know how some prolific bloggers in the SAP sphere manage to get any “real” work done to earn their livings.

The constantly shifting technology requirements are bad enough but it is SAP’s constant commitment to seemingly re-invent every wheel they can find and somehow get an SAP badge on it that is becoming my biggest bug-bear.

Boxy but Safe

At TechEd a couple of years ago, my colleagues and I were pleasantly surprised by the NW 7.3 news that SAP would be opening up to more industry standard UI technologies, such as HTML5, jQuery, JSP, JSF, etc.  We saw this as a big step forward enabling customers to deploy qualified UI specialists to work alongside SAP business logic specialists to deliver truly feature rich solutions that were finally no longer grey and blue.  It really could all become about the user-experience.

I’ve always likened SAP’s traditional grey and blue UI theme to Dudley Moore’s character in the film Crazy People, commenting on a certain Swedish car maker’s approach to design - Crazy People

It was disappointing to hear ABAP Web Dynpro would become the de facto UI technology and Java Web Dynpro would no longer be developed but we all agreed opening the platform up to “industry standard” UI technology more than made up for it.  And of course, we knew this situation wouldn’t last forever…

Highlander

This (eventually) leads me on to my main point, and it strays away slightly from John’s original thoughts about SAP Developer skillsets changing although is highly related in my eyes…  I’d love to see some rationalisation of technologies from SAP.  The development workflow, architectural decisions and day to day tasks moving away from the current spiders nest of technologies, layers, stacks and standards.

Why can’t we have a single, integrated service/resource/integration layer (this started off as a SOA layer but I was reminded not everyone is happy with that approach - SOA #fail ) ?

A development environment that “does it all” and supports a one true integration layer (currently Gateway but I’ve taken an hour or so to write this blog so it may have changed) to enable all UI channels.  I’m going to give this nirvana development environment the codename “Highlander” for hopefully obvious reasons - Highlander

As an SAP development architect with ranging skills and responsibilities, it pains me that I can’t use one environment for development of ALL solutions.  I can use NWDS for many tasks now, which is a big step forward but I won’t be happy until I can do EVERYTHING – ABAP, Web Dynpro, BPM, PI, Gateway, Mobile, Responsive UI, HANA, etc. – in a consistent, feature-rich environment.  It doesn’t have to be NWDS, I still love SE80 for instance.  Or start again from scratch, I kind of don’t care.

Why do I have to consciously think about the varying layers needed to expose a piece of business logic via mobile, or via the Portal, or via a traditional Dynpro?  Why should I need to worry in a different way if I want my data to be available off-line in a mobile application?

Why can’t I simply focus on pure business logic functions* and then chuck whatever UI channel I want on top, all from within the same environment with common, standardised development workflows, wizards and tools?  Completely decoupling the logic from the UI and not suffering imposed constraints from one to the other.

*I wanted to write SOA services here but DJ Adams might lynch me   Joking aside, as a business logic developer, why should I need to sweat over whether my function will be available via SOAP, RFC, REST, oData or whatever other combination of integration protocol(s)?  I really shouldn’t need to worry about that detail.  And as a UI developer, why should I care how much pain my colleague has had to make his logical units of work cope with concurrent users?!

I really shouldn’t need to think “this function is going to be consumed by a mobile application so needs to be built using method A” or “this is a function for a SAPUI5 application so needs to be built using method B” etc…

The Highlander Stack

I’m conscious this is a particularly dull blog, with too much text and not enough images, so here’s my vision of the SAP Highlander Development environment.  It’s pretty simple:

I’m not asking for too much am I?  (And yes I know I've over-simplified lots, made sweeping statements and assumptions and generally ridden rough-shod over lots of stuff but my important question still stands - why is it all so complicated?!)

Elephant in the Room

I’ve deliberately not mentioned much at all about SAP licensing strategy in this post – many people with a much better understanding of the process have done this to death already.  What I will say is that SAP seem hell-bent on producing clever technology solutions, then licensing those solutions out of the grasp of many typical SAP customers.

I was fortunate enough to be invited to participate in the Bloggers Program at SAPPHIRENOW in Orlando last week.

One of the more interesting announcements (at least for me) was "SAP Fiori" which was demonstrated during Vishal Sikka's Thursday keynote by Sam Yen. Vishal spent some time explaining that "Fiori" means "flowers" in italian and why that name was chosen. The Fiori apps were also being demonstrated on the show floor and are available now.

Sam Yen has the job of "changing the perception of usability at SAP". Not a trivial task. You can refer to my blog about this from SAP TechEd season last year. http://scn.sap.com/community/ui-technology/blog/2012/12/19/changing-perception-of-usability-at-sap

Part of Sam's strategy is to identify the most common SAP transactions used across the SAP customer base and "renew" them. When I was talking with Sam last year he suggested that this would be around 20-50 scenarios. The initial release of Fiori apps number 25.

In the latest SAP User Interface Technologies Road Map document SAP use the terms "Top use scenarios" and "Core use scenarios".

The same road map document shows that over time SAP will renew "top" and "core" scenarios progressively.

All this is good news for SAP customers. Let's face it - any initiative to get the SAP delivered user experience closer to what the end-users desire is to be applauded. Fiori apps are built using the SAP UI5 framework on the front end which calls backend functionality that is exposed using NetWeaver Gateway services. This should mean that Fiori apps can be ported to any version of ECC 6 - and potentially even further back. I look forward to hearing how easy this is in reality. (*Important - SUP - now known as the SAP Mobile Platform - is not required.)

If nothing else the Fiori apps are a good demonstration of how to build web applications from both an architectural and user experience perspective. The clear separation of user experience and backend functionality is a principle that all architects and developers should have grasped by now. The screens are simple and in many ways quite minimalist. Most liked them and even the worst criticism I heard was pretty subjective. The responsive design seemed quite good although I didn't get a real chance to try it out on a smartphone to see how usable it was on that form factor was.

The bundle of 25 Fiori apps are priced at 100 Euro per user. There are plenty of people who believe they should be free and there was a robust twitter discussion about this. I also had many people seek my opinion on this aspect both directly and indirectly. Personally I believe that they should be free but I am not militant about it. SAP could use the goodwill that such a move would provide and I think that it would reinforce the message that fixing the user experience is SAP's problem not their customers'. But I also understand the argument that by putting Fiori on the price list the SAP field sales force will be motivated to position it within every customer. The continuation of this argument is that it will increase visibility of the Fiori apps within the customer base and therefore adoption. Time will tell I guess.

What I am sure about is that the availability of NetWeaver Gateway for all SAP customers without additional licensing costs greatly simplifies the Fiori licensing discussion. So if nothing else SAP can be happy that the change in pricing policy for Gateway helps simplify the Fiori pricing discussion.

On the exhibition floor I was incorrectly advised that if additional apps are added to the Fiori bundle they would be covered in the license cost. This didn't sound right to me so I tested this with Sam Yen and he confirmed that wasn't correct. The problem here is that if more apps are "renewed", as indicated in the roadmap slide, then SAP will have their hand out again for more Euros. This would not be a good look. SAP need to sort this out quickly. Of course I needn't point out that this problem goes away if Fiori apps are free.

Another source of confusion came from a SAP source that asserted Fiori apps were targeting so-called "occasional users". This flies in the face of every message we have received since this initiative was started last year. On the Fiori overview page it clearly states that they are "for broadly and frequently used SAP software functions" - pretty plain to me. I understand that sometimes people get the messaging wrong but the people that were responsible for this snafu did themselves no favours at all.

As to the Fiori apps themselves, they are catalogued as Manager Apps, Employee Apps, Sales Rep Apps and Purchasing Agent Apps. They include…

• eight different workflow approval apps as well as a baseline app you can use to create your own approvals
• an app for budget and spend information for departments and projects
• employee apps for leave requests, time sheets, travel requests, pay slips, benefits
• shopping cart apps for purchasing
• sales support apps for pricing, availability, sales orders, shipments, invoices

The first thing that occurs to me is that there is significant overlap with existing web/mobile solutions that SAP provide. I wonder how SAP will position the Fiori Employee Apps against Employee Self-Service? Between the Manager and Employee Fiori Apps a significant proportion of what is currently in  ESS/MSS is covered. And every SAP Mobile pitch I have seen puts plenty of focus on workflow approval apps. There seems to be a school of thought that workflow approval is the mobile "killer app" - something I strongly disagree with.

As for the apps themselves they look pretty good. We all have different tastes so they won't be for everyone but the good news is that there is a theme builder that allows you to change their appearance to suit yours. The apps all look and work consistently which is important so the users can figure out how to drive quickly.

SAP have recognised that many customers, maybe all customers, will need to modify at least some of the delivered apps to suit their particular needs. There is already documentation available that shows ways of doing this. In the future the Applications Designer tool has a part to play here but unfortunately this tool has been delayed and is not yet available.

So all in all I would have to say that the Fiori Apps are a good initiative. They look good, they are simple and easy to implement, and they are targeted at a clear need in the SAP community. I now wait to see how quickly and how widespread the adoption of these apps is. And returning to the roadmap slide I am reminded that the "renew" slice is targeted to grow over time. If SAP can come up with 25 apps in the 6 months since last SAP TechEd season can we expect another 25 for the next SAP TechEd? I hope so.

Its long been known that the same effect that oil and water have when mixed can often be used to describe SAP and UI.  What with the multitude of products such as BSP, WebDynpro (abap and java), WebUI and classic GUI, users often cant see the forest through the trees. 

But I think the light is starting to appear at the end of the tunnel.

SAP is finally making a committed effort to pay more attention to the user experience.  But what does this mean?  There are some things to consider, as we embark down this road.

Improving OOB UIs yields only a partial win.

First and foremost, no matter how good the out of the box UI is (or will be), it will always need modification.  Its great that there is renewed focus on “getting it right” in terms of the products that are being rolled out of the box, but there will always be the need to modify, tweak and adjust - sometimes more, sometimes less.  The key isn’t necessarily sprinkling some pixie dust on the computer and coming up the best UI out of the box that everyone will love, because not everyone will.  There will always be the concept of the split vote when it comes to the user interface.

Easily allow modifications.

Typically, users who own SAP products will at some point want to modify those products.  This is the age-old adage – should your company change to revolve around SAP, or should SAP adapt to your company.  We see the latter as the norm.  Customers want to modify OOB for many reasons – blend with other non-sap assets, integrate with public facing content, branding requirements, and so on.  Allowing customers to easily modify to their hearts content always was, and will continue to be a critical success factor for SAP UI adoption.  Please don’t think that the OOB UIs are good enough.  Good enough is not a concept easily accepted with customers, so SAP UIs should be flexible enough to accommodate easy change.

I see potential with new cloud based solutions and also SAP Personas, where in the case of cloud solutions (within 360), the OOB UIs are improved, but customers are already asking how to modify to align with their other assets.  Smoothing and seamlessness is key, so this requires customizing cloud based UIs.  Again, make it easy and fast.  And in the case of Personas, this allows backend classic UIs to be “powerpointed” if you will, as drag and drop and background images become the norm.  Although better than forcing users to confront and navigate thousands of UI options such as with Creating a PR  / PO in ECC, users can delete buttons and fields not needed with Personas, and provide some branding and contextual removal of unwanted fields.  Some limitations continue to be full smoothing and polish, when aligning to a corporate style guide pixel for pixel, but nonetheless is a better option compared to standard ECC screens.

In the end, renewed focus on the user experience will bode well, as long as wins aren’t based on the false assumption OOB alone will suffice, and that UIs should anticipate and facilitate modification, to fall inline with customer wants and needs.

There are a host of UI technologies available, and the list is growing.  I am finding that SAP customers are confused about what UI technology to use when, particularly as there is a moving target.  There doesn’t seem to be any great assistance from SAP to help customers through all the options to determine what solution best matches their requirement. 

I certainly don’t pretend to know the answers myself, but when I’ve seen other blogs on the subject, either the details are out of date, or the content is incomplete.  So these are my thoughts on a simple framework for thinking about what approach might be the best fit for different scenarios.

On premise, on device, on demand.

SAP’s technologies cover 3 architecture scenarios:   • On premise.  Traditional SAP server-based installation at the customer.   • On device.  Mobile solutions for tablets and smartphones   • On demand. Cloud-based/hosted services   A customer may have a mix of product architectures across their solution landscape.  Business requirements, available solutions and services, and the sales model of the software will drive the decision for the architecture.

Apps

First I’d like to consider what we mean by an ‘app’.  Apps can run on desktops, on mobile devices, or in the cloud.  They add rich client-side functionality and can be designed for complex or multiple tasks.

Desktop apps

SAPGUI is of course that traditional client/server application where some functionality is handled locally such as personalization settings.  Netweaver Business Client (NWBC) can be used as an alternative to SAPGUI.  This has a more web-like interface, but the SAPGUI transactions are exactly the same.  Traditionally, developers build custom transaction screens, and Floorplan Manager (FPM) provides a fast framework for building SAP applications. The typical use-case is for expert or professional users who process complex business transactions.

Mobile apps

Mobile apps can be custom-built or off-the shelf applications, designed to do a small number of functions very well.   They can be designed to store data locally, and synchronized to SAP back-end using Sybase Unwired Platform.  Alternatively they can be designed to use SAP Gateway for real-time integration to SAP database.

Cloud apps

With cloud apps, the application is hosted externally and the customer purchases software as a service, running through a web browser, so no software is required on premise or on device.  Customers would not typically design these themselves.   For SAP customers and partners who want to build cloud apps, then the SAP NetWeaver Cloud Portal can be used for easy application creation, and sales through the SAP store.

For custom SAP functionality, you would consider whether such functionality is already available as off-the-shelf application, such as a SAP add-on, a mobile app, or cloud-based offering.  If you decide to build your own application, then you should decide whether the application should be accessed through SAPGUI, or whether a mobile application is required.  Then benefit of a mobile application is when data is stored locally on the device as part of the application; if the mobile application can only be used when on-line, then this is little more than a web portal, so the management effort of the apps (using Afaria for example) may outweigh the benefits of the app.

Web (portal) screens

I’d prefer to avoid the term web dynpro, since there are multiple technologies available for building custom web-based screens:  Business Server Pages, ABAP Web dynpro, Java web dynpro and SAPUI5.

Despite how new the software is, it is difficult to imagine not using SAPUI5 for designing new web-based functionality.  It’s certainly the direction we’ve chosen for FLM, having previously used both Java web dynpro and BSP.   With SAPUI5 you can design once and support many different browsers, such that this provides a desktop and a mobile solution.

With SAPUI5 you can build rich controls with easy integration to SAP.  You can host the SAPUI5 solutions on any web server, so you can host on the SAP ABAP stack, for example.    With this approach you are ‘front-ending’ SAP BAPIs and transactions – either pre-delivered or custom-built –with a web-based interface to deliver simpler or more usable screens for your users.

In those scenarios where customers are front-ending a SAP Workflow with a web screen, using the screen to collect data and push on to the next user, without the need for deep SAP integration while the data is being collected, then they are probably using the wrong technology, and should consider an e-form instead.

 
E-forms

I’ve written a lot about E-forms (SAP Interactive Forms by Adobe and Forms Lifecycle Manager) in other blog updates, so I’ll try not to re-tread old ground.  E-forms provide another user interface solution, and here we consider both on-line and off-line scenarios.

For on-line forms, the form is accessed using a web-browser. For HTML / HTML5 forms, then that is all you need.  For PDF forms, then the embedded Adobe Reader is required, which does not support e-forms on mobile devices.  In the past, a lot of development effort has been required to embed the on-line form inside a custom web dynpro.  But now this is not required, and the form can be delivered through web dynpro, BSP or SAPUI5* without any custom development using FLM.

For off-line forms, the form is accessed using Adobe Reader, and typically downloaded manually or sent via e-mail.  Off-line forms are PDF rather than HTML, since the PDF can store the form data locally; each form is like a mini application.

Although I have seen many complex e-forms, I advocate that they are most useful when kept simple.  We should expect forms to change, and so they should not be used to front-end an entire SAP transaction or BAPI – they should be used to collect, verify and route data from and around the organization, triggering updates to SAP when appropriate. 

E-forms typically have 2 integration points with SAP: Pre-population (pre-render) and Validation / Update (post-submit).  This means that drop-down list options are fetched before the form is rendered, and there is a ‘single shot’ update of the form data back to SAP, rather than lots of data transmission on a field-by-field or section-by-section basis.  That’s how we keep them simple, easy to maintain and fast in performance.

Companies should not invest deeply to build a single e-form, as they should be fast and cheap to develop.  When organizations spend months building a complex on-line form to front-end an SAP transaction (such as ‘create customer’) then probably they are using the wrong technology, and they should consider a SAPUI5 approach instead.

Companies should have hundreds of simple e-forms that are easy to change, look great and are easy to use for the occasional user.

 
Choosing the right approach

I was tagged by Anthony Bennett in his Blog It Forward post a few weeks back.  You can find out more about the challenge here and track it here.

Like Anthony this is my first blog on SCN after being a long time reader.

I’m Stephen Kringas and I have been working as a SAP consultant in Australia for the last 7 years.

Prior to working in SAP, my passion was snowboarding. I had been snowboarding since I was 15 and would save all my money each year to head over to USA or Canada for 3 months at time and do nothing but ride. It was an incredible part of my life being able to see great places such as California, Utah, Whistler, and Japan. However that endless winter dream finished after I’d sustained too many injuries over the years, including a broken thumb,  broken wrist, 2 knee reconstructions with the final straw being a fractured vertebrae. After that one I decided it was time to settle down and get real job

I started as a graduate at SAP Australia primarily focusing on Web Dynpro Java back in 2005. I am very grateful for getting the opportunity to work in SAP because I’ve been able to work with so many great people and have travelled to Hong Kong and USA for a couple of projects.

Anthony was a great help getting my career up and running, providing both technical and consulting skills over the years and also becoming a great mate. Since my WDJ days I’ve moved into WDA and more recently mobile development (mainly with the Kony/Sky Technologies platform)

Outside of work my other passion is my family; my wife Elisha and 2 kids, Oliver (nearly 3) and Victoria (1). Its been a rollercoaster ride this whole parenting thing but watching them grow up and learn new things is such a rewarding experience.

Below is a photo of my 2 lovely kids (and monkeys) and a photo of me snowboarding in Canada which I still hang onto so I can relive the "glory" days

Which 5 things do you absolutely want to achieve in life?

• See the kiddies grow up and thrive

Just looking forward to seeing the kids go through each phase of their life….might want to skip the teenage years but the rest should be good

• Take a Jet Fighter for a spin in Russia

It was always a dream to be a fighter pilot and recently I found a Russian air force base where you can fly 4^th generation jets like the MIG-29 / Sukhoi  SU-27. Truly would be a once in a lifetime experience!

http://www.flymig.com/aircraft/

• Heli-board in Alaska

Would love to go heli-boarding in Alaska just to experience ridiculously long runs with deep powder....no jumps of course.

• Complete the family home

Currently we’re designing the dream family home here in Melbourne. Its ridiculous how many things need to be decided on, get approval for, and then to manage all the stuff. Its worse than organising a wedding!

• Retire and become a “Grey Nomad”

        Grab a caravan and travel around to Australia’s beautiful destinations while mingling with all the other “Oldies”

What 2 things do you like the least about working in IT?

• Documentation

Love the design and build phase of my work but have always hated doing documentation and have a horrible habit of putting it off until the very last minute

• Meetings

I don't dislike all meetings; its just the ones that are really inefficient and could have been covered off in half the time. I’d just much rather be at my desk coding or doing something else more productive.

What 2 things do you like the most about working in IT?

• People

Over the years I’ve been lucky to have worked with some great people, not just from a technical perspective but also on a personal level. It just makes work that much more enjoyable and rewarding working on projects with a couple of mates while getting the job done.

• Problem solving and constantly learning new things

I got into IT originally because I loved problem solving; computers just happened to be the tools that I used. The other aspect I love about IT is the constant change meaning it never gets stale and there is always something new to learn. Often I think how great it would be to take a few months off just play with all the latests and greatest stuff because it can sometimes be difficult to experiment while working on your regular stuff.

I’ll pass the Blog It Forward baton to Praneel Kumar and Pran Bhas.

The questions for Praneel and Pran are:

• Share an interesting/funny story related to a project
• If you were not in your current position, what/where would you be and why?

Cheers,

Stephen

SAP NetWeaver Business Client 3.5 contains many enhancements,
particularly in the following areas:

• Navigation
• Personalization
• Search
• Role Maintenance
• Administration

Some of the highlights in Navigation, Personalization, and Search are
demonstrated in this short video (2:00).

For more information, see the SAP Library documentation “What’s New in
NetWeaver Business Client 3.5” http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4c/5b13bf97817513e10000000a42189b/frameset.htm

This weblog will demonstrate how easy it is to implement a jqPlot chart within BSP pages.

For developers who can't wait for UI5 with integrated chart engine and don't want to use webdynpro charts, it is possible to implement one of these javascript chart engine. There are various javascript chart libraries available with different license aggrements: Highcharts, RGraph, flot just to name a few. For this example here, I choose jqPlot, because it's simple to use, looks pretty and has a lot of chart options. See some demos for jqPlot here.

First we need a small BSP page which selects some data in "OnInitialization" Eventhandler:

* event handler for data retrieval
 SELECT *
   FROM sflight
   INTO TABLE flight_tab.

Table is defined as page attribute:

flight_tab    TYPE    TY_FLIGHTS

Layout:

To implement jqPlot it's necessary to load some scripts. jqPlot depends on jQuery, so we need that too. For this example I didn't link to these js-files direclty, as in some companies Internet access is handled very strictly (I know, it wouldn't make sense to view this BSP page on a mobile device which normally has internet connection, but think of VPNs). To do that just import your JS-files as MIME object into your BSP applikation.

Now we can link from our BSP site to these resources in HEAD part:
(you can copy following code snippets into your BSP code view, all necessary coding is shown in this blog)

<!DOCTYPE html>
 <%@page language="abap" %>
 <%@extension name="htmlb" prefix="htmlb" %>
 <html>
 <head>
   <meta charset="utf-8">
   <meta name="viewport" content="width=device-width, initial-scale=1">
   <title>jquerymobile page</title>


    <link rel="stylesheet" href="jquery.jqplot.min.css" />
   <script src="jquery-1.7.2.min.js"></script>
   <script src="jquery.jqplot.min.js"></script>
   <script src="plugins/jqplot.dateAxisRenderer.min.js"></script>

To have all jqPlot plugins available for more plot options, just insert all ".min.js" files into a plugins folder. We'll only need dateAxisRenderer for this example, but if you want to play around with different chart styles you can import all plugin files at once.

Now we can prepare our data for jqPlot array. jqPlot date plugin needs date values in a special format (CCYY-MM-DD). So I insert some quick and dirty coding to build this array (I know it's not JSON standard, but that's the way jqPlot understands data inputs):

   DATA:  lv_line1 TYPE string
         ,lv_price TYPE char20
         .
   FIELD-SYMBOLS: <fs> TYPE sflight.
   
   CLEAR: lv_line1.
   
   LOOP AT flight_tab ASSIGNING <fs>
   WHERE carrid = 'LH'.
     lv_price = <fs>-paymentsum.
     CONDENSE lv_price.
     
     CONCATENATE lv_line1 `['`
                 <fs>-fldate(4) `-`
                 <fs>-fldate+4(2) `-`
                 <fs>-fldate+6(2)
                 `', `
                 lv_price
                 `], `
            INTO lv_line1.
   ENDLOOP.
   
   lv_line1 = `[` && lv_line1 && `]`.

Now ABAP variable "lv_line1" has necessary data string in it. With next code snippet jqPlot options are defined via javascript:

<script language="javascript" type="text/javascript">
 $(document).ready(function(){
     var line1 = <%= lv_line1 %>;
     var plot1 = $.jqplot('chart1',[line1],{
        title: 'Lufhansa flights',
        stackSeries: true,
        showMarker: false,
        axes: {
            xaxis: {
                renderer: $.jqplot.DateAxisRenderer,
            }
        }
     });
 });
 </script>
</head>

The only thing what's missing here is where this chart will show up on our website. We just need to insert one html DIV element in BODY part.

<body>
 <div id="chart1" style="width:500px;height:300px;margin-top:40pt;"></div>
 </body>
 </html>

And that's the complete output in a browser:

In this example different currencies aren't respected at the output, which comes directly from flight table!

Style enhancement

You can use popular jquerymobile framework, which gives you possibility to build a nice mobile webpage with a great user experience. Full coding for BSP layout is available at https://gist.github.com/2910208

See more ideas by me on G+

Hi All,

We would like to invite you to join the great UI survey of 2012. This survey reviews which (SAP) UI technologies you are using in your company to develop your customer web applications and as important - which technologies will you use when starting a new project. This is the second time we are doing this survey, the last one done a couple of years ago, so the results of this survey will be very interesting both to understand which technologies are being used and to see what can we learn from the 'trend' compared to the previous survey. The Survey is conducted together with ASUG, under the umbrella of the ASUG NetWeaver UI Influence Council (which is headed by Karin Tillotson and myself) and after the first phase of gathering the feedback from the ASUG development SIGs, we are now opening it up to the entire community.

The results of this survey will be presented at the 2012 ASUG Annual Conference in Orlando, in an anonymous and summarized fashion, so no worries.

SAP will be using the results of this survey as input to our development strategy to better understand what our customers are doing with UI (as part of the Influence process).

So - what are you waiting for? Time to influence - click here to access the survey.