* Disclosure – I’m not affiliated with Kony Inc. At my current client I’ve built Mobile Apps using Sky Technologies (who Kony purchased in 2012). After attending a training course for Kony Dev and I wanted to share that knowledge and show one of the many ways that you can “Mobilize” your SAP data via Gateway.


Introduction

The number of options available for accessing your SAP data/systems via mobile devices has increased dramatically in recent years.

One of those options is to use the KonyOne platform. Previously it has been difficult to get access to Kony’s development tools/platform unless you happened to work at one of their customers or partners. Recently though Kony has started to offer free trials to its new Development Cloud platform

One of benefits of the Kony development allows you to target a large number of channels all using the same code base that is written using JavaScript. The KonyOne Studio is an Eclipse based IDE.

Kony_BuildTargets.png

KonyOne has 3 general approaches for building mobile applications that integrate with SAP –


  • Sky Mobile Add-In (Kony acquired Sky Technologies in August 2012)
        • Recommend for more complicated apps (Complex Data, Offline etc)
  • SAP NetWeaver Gateway
        • Recommended for less complex / online use cases.
  • SAP JCo
        • I guess if you want to integrate with existing RFCs you may use the JCo approach…

Similar to an earlier blog I wrote which used Appcelerator, I’m going to build a simple Kony Master / Detail application which consumes the Trial SAP Gateway Business Partner service.

Prerequisites


  • Kony Cloud Development Cloud account
  • Local Development Setup (Applicable SDK’s installed, Kony IDE & Server following the install guides)
  • Access to the Trial Gateway services or similar –

http://scn.sap.com/docs/DOC-40986

http://scn.sap.com/docs/DOC-31221

Giddy Up Kony….


1. Create the Application / UI


a. Create the Application / Project


Lets start by creating the Application/Project in KonyOne Studio

Kony_AppCreate.png

Below is the default structure for newly created projects –

Kony_Project_Structure.png

Sub-Folder
Description
Forms Where you create the UI for the application. The forms are separated out into 3 sub categories Mobile / Tablet / Desktop
Modules Place custom JS files in here (By default the konylibrary.js file is included)
Resources Application assets such as images etc.
Services Can define different services that the application will utilize

b. Define 2 Mobile Forms for the UI

Kony_Create_Forms.png

Master Form

This will display the Business Partner No. and Names returned from the Gateway service. Using drag and drop you place the widgets on the form. Also make sure you update the ID’s of each UI element to something more meaningful than the default generated ID. This will help you reference the correct widget when coding & mapping data in the form.

Kony_Master_Form_Layout.png

Kony_Master_Form.png

The Segment Widget is used for displaying lists/tables of data. In addition to the BP Number & Name, we’ll define 4 hidden columns to store additional data which won’t be visible to the user. These hidden columns will be used later to pass data to the Detail Form

Kony_Master_HiddenColumns.png

Detail Form


When the user selects a specific Business Partner, the application will navigate to the detail form which shows additional information. The form will comprise of Labels, Buttons and a TextArea widget to display the relevant information & actions (Click to dial, email etc).

Kony_Detail_Form_Layout.png

Kony_Detail_Form.png

2. Define Business Partner Service

Now we need to create a JSON service definition which will connect to the Gateway service to retrieve the Business Partner details. The service definition will be deployed to the Kony Development Cloud.

a. Define the JSON Service

Firstly navigate to the JSON service definitions and select the “Add Service” option ->

http://farm8.staticflickr.com/7313/12303054026_c6001cb61e_z.jpg

http://farm4.staticflickr.com/3735/12303054056_5c48a12957_o.png

The application is going to be utilising the following URL to retrieve the BP Data ->

https://sapes1.sapdevcenter.com/sap/opu/odata/IWBEP/GWDEMO/BusinessPartnerCollection?$format=$formatv

http://farm8.staticflickr.com/7305/12302662413_4386300a1b_o.png

b. Define the Input & Output Parameters

Kony uses the “$” symbol as a placeholder for input parameters so I used a little work around to call the service with the parameters I needed.

For the input IDs in the below screenshot –

  • format – Will be used to append the OData query option “$format” to the URL
  • formatv – Will specify the response format; in our case we’ll be requesting the response in JSON format

Enter the UserID / Password and click the “Get Response” button

Kony_Service_Input.png

In the Response tab at the bottom of the screen, it shows the data that has been returned from the service. We can use this information to define the output structure/collection that will be used in the application.

This is configured on the “Output Parameters” tab.

Kony_Service_Output.png

After defining the output structure, click the test button to validate the returned data (based on your test input parameter values) and output structure are as expected.

Kony_Service_Results.png

*NOTE – This is sample data being returned from the Trial SAP system *

c. Add the Service to MyLittleKony

Once you are happy you need to “Add” the newly defined service to your application so it is available for use. The service definition can also be reused for other applications in the future.

Kony_Service_Add.png Kony_Service_Selected.png

d. Deploy the Service to the Kony Development Cloud

Now we need to publish the service to our Kony Development Cloud by following the steps below –

Kony_Service_Publish.png

Kony_Service_Publish_Cloud.png

Kony_Service_Publish_Success.png

Now the service has been successfully deployed and now is ready for consumption.

3. Implement logic to Consume the Service

a. Call the Gateway Service on initialisation

On the Master Form properties, find the Event “init”. We’ll use this event hook to call the Gateway service when the application is initialised.

Kony_Master_Init.png

In the Event Editor you build the action sequence that will be executed when the applicable event hook/action has been triggered.

http://farm6.staticflickr.com/5540/12303782355_c6d7ea72f4_z.jpg

For this init action sequence I’ve defined the following ->

Kony_Master_Init_Seq.png

Action Step Description
Snippet:kony.appl…

This is a small code snippet which is executed first to display the Loading/Processing widget->

kony.application.showLoadingScreen()

Asynchronous Service: GatewayBpQuery Select which service we want the application to call. Also by clicking the “Open Mapping Editor” we can define the values we want for the 2 input parameters
Decision: status == 400 & true When the callback sequence returns status of 400, the data has been returned from the service and the “true” action sequence will be executed
Snippet:kony.appl… Dismiss the Loading Screen by adding the code snippet -> kony.application.dismissLoadingScreen()
Add Mappings Map the data returned from the service to the applicable columns and attributes in the Segment widget on the Master Form

Mapping Editor for the Service Input Fields ->

Kony_Master_Init_Service_Map.png

Mapping Editor for the Service Result to the Form elements/columns ->

Kony_Master_Service_Response_Map.png


b. Create Custom JS Modules

Create 2 JS files in the Modules section in your project structure.

http://farm4.staticflickr.com/3672/12304383265_c4a75d83bc_o.png

frmBpMasterJS.js

A single function which will be called when the user selects a BP from the master list. It retrieves the data from the selected row, including the hidden columns and then assigns them to the applicable Detail form widget.


Finally navigate to the Detail form using the show() method.


function onRowClick() {
 // Get the selected item
  var row = frmBpMaster.segBpList.selectedItems[0];
 // Populate the Detail Screen
  frmBpDetail.lblBpNumber.text = row.lblBpNumber;
  frmBpDetail.lblBpName.text = row.lblBpName;
  frmBpDetail.lblBpPhone.text = row.bpPhone;
  frmBpDetail.lblBpEmail.text = row.bpEmail;
  frmBpDetail.lblBpWebsite.text = row.bpWebsite;
  frmBpDetail.txtareaAddress.text = row.bpAddress;
 // Navigate to the Detail Screen
  frmBpDetail.show();
}









frmBpDetailJS.js

The custom Detail JS file contains some basic functions to handle the click events when users select particular BP Details


// Launch the Native Email Client
function onEmailClick(){
  kony.phone.openEmail(frmBpDetail.lblBpEmail.text, null, null, "My Little Kony", "Giddy Up", false, null)
}
// Open the Browser and Navigate to Website
function onWebsiteClick(){
  kony.application.openURL(frmBpDetail.lblBpWebsite.text);
}
// Dial the BP Phone No.
function onPhoneClick(){
  kony.phone.dial(frmBpDetail.lblBpPhone.text)
}








c. Link the Functions to the UI Widgets

Link the Functions to the correct events for the respective Widgets

Kony_Detail_Phone_Click.pngKony_Detail_Web_Click.pngKony_Master_RowClick.png

4. Build / Run the Application


After saving the application, select the Build -> Clean & Build option for the application.

http://farm8.staticflickr.com/7401/12299473326_c2c899cdbb.jpg

Select the required targets.

http://farm4.staticflickr.com/3697/12304631765_7e75f92d51_z.jpg

After the build is complete you can run the application using the configured emulators (or on the device if you’ve configured that option)

http://farm3.staticflickr.com/2894/12304631825_33e734304d_o.png

Below are some screenshots of the MyLittleKony App running on iOS / Android / Windows Phone.

Note the application is using the default skins for each platform so they aren’t the “prettiest” looking screens. The Kony studio does give vast number of options for customising the look and feel of your applications but it can be tedious with the current IDE.

The good news is Kony have released the Visualisation Cloud which will make the process of skinning the UI a whole lot easier. The tool looks very similar to the SAP AppBuilder used for SAPUI5 applications.

Kony_IPhone_Master.pnghttp://farm3.staticflickr.com/2864/12299468136_28a3ba8ff8_z.jpg

Kony_Android_Master.pngKony_Android_Detail.png

Kony_WinPhone_Master.pngKony_WinPhone_Detail.png

Resources

Below are some additional resources where you can find further information about the KonyOne Platform.


http://www.kony.com/resources

http://www.kony.com/products/development/resources


More resources & tutorials are available when you sign up to the Developer Cloud .

Cheers, Stephen

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Brad Pokroy

    Another great blog Steve! Really cool to see the different options available out there. Keen to take a look at the KonyOne platform sometime.

    (0) 
  2. Sukanta Rudra

    Stephen.

    I had never expected to see a blog on Kony platform on SDN. ( as it happens to be an non-SAP product). We have been using Kony platform to deliver one of our implementation. Initially there was struggle trying to understand things, debugging, and making the application run on devices. Things have stabilized lately and things look positive now.

    Although we have been using SKY Gateway, I never did know about connecting SAP using Gateway, until I read this blog.

    Thank you Stephen for the complete example using Gateway & Cloud platforms.

    S Rudra

    (0) 
    1. Stephen Kringas Post author

      Hi S Rudra,

      Thanks for the feedback. Regarding Kony, really I just wanted to highlight one possibility for consuming SAP data via Gateway. Also the Sky Add-In (Sky Technologies), which is the integration approach you’d most likely use if you’re building SAP mobile apps with Kony, has been a SAP certified ABAP add-in for a number of years now. Probably one of the reasons Kony purchased Sky Tech, back in 2012.

      Good luck with your mobile projects!

      Cheers,

      Stephen

      (0) 
  3. Riley Rainey

    Stephen,

    I read your article with interest and a small bit of surprise — the Unicorns have finally arrived at SCN.

    I have some technical experience with both Kony and SMP, having worked at both Kony and now in SAP’s Mobile Software group.  I have to say that I strongly prefer SAP’s approach to mobile application development.  There are many reasons behind my position; I’ll try to lay out the principal ones here:

    • While both platforms support Hybrid Web Application development, SMP’s Hybrid architecture is far more open and flexible – Apache Cordova (and even the V2.3’s PhoneGap-based equivalent in HWC) offer true choice of HTML5 UI Frameworks. The Sysco Counts app is a great example of ‘write once, run many’ application build atop SMP.  Kony’s JavaScript APIs are proprietary to Kony, as is its form layout engine.
    • SMP offers a true choice of client architectures.  SMP Native is true native — that is, something developed using native tooling and providing MEAP functionality through class libraries.  Kony’s ‘native’ application architectures are simply a JavaScript execution engine, Kony-specific APIs with a UI abstraction layer mixed in — hardly native by any stringent technical interpretation.
    • SAP’s UI5 offers modern Responsive Design capabilities and a true Model-View-Controller architecture.  SAP’s popular suite of Fiori applications are all developed using SAPUI5.  UI5 can be used to develop desktop, tablet and phone applications in mobile web and SMP hybrid container apps.   Kony Studio’s multi-channel approach is something less than Responsive.  Kony Studio’s approach is more compile-time oriented where Responsive is run-time oriented.  Kony Studio’s bucketing forms into Desktop, Tablet, and Phone categories fails to completely account for the varieties of device form factors that are available today.  The result is a less adaptable user experience.
    • SMP 3 Application Services are exposed as OData web services, where Kony supports only simple JSON.  OData services offer a number of truly useful extensions over a JSON/REST approach — data pagination, dynamic data reshaping and batch processing are examples of standard OData Judo moves.  An SMP mobile app developer has these and more at her fingertips, where a Kony developer would be required to consult the services development team to make changes – that costs time in both development and testing – and, as the saying goes, “time is money”.

    Kony’s platform has its origins in B2C development.  To me, it hit its zenith in the time when B2C application authors commonly faced the challenge to produce apps quickly for iOS, Android, BlackBerry, Windows Phone and maybe even Symbian.  But that was several years ago.  Today’s field of device OS players has narrowed from five to two or perhaps three.  This smaller field calls into question the fundamental value proposition of a tool designed to “Run Everywhere”.

    Regards,

    Riley Rainey

    (0) 
    1. Gregor Brett

      Hi Riley,

      While I agree with you, I have to point out that much of the same complaints can be levelled at Syclo Agentry (which is part of SMP). Perhaps these proprietary metadata driven approaches have had their day?

      (0) 
      1. Riley Rainey

        Gregor,

        Agentry’s client architecture – what SAP calls the Metadata-driven architecture in SMP 3 — definitely has all the characteristics of a write-once, run-many approach.

        As you point out, if one compares it to the Cordova/Kapsel client, it is easy to come to the conclusion that Cordova is a more open starting point.  But a developer sometimes would prefer to start with something other than a blank piece of paper – and that’s where Agentry shines.

        The SAP Syclo SMART Suite – Work Manager, Rounds Manager and others are all implemented as Agentry (MDD) client apps.  These are ready-to-run Field Service and Asset Management applications.  Out-of-box integrations to SAP and other back-ends make it easy to have these applications up and running quickly.

        From a developer’s point of view, though, I can license the source code of any of these applications to create highly tailored solutions, substantially reducing the risk, time, and cost of a “blank paper” approach.  There are also components of Agentry’s server and back-end technologies that are now key elements of the SMP 3 Platform so it is safe to say that the Agentry client will be with us for quite some time.

        (0) 
    2. Paul Boris

      Riley – great analysis.

      can you expand a little on building quick / sustainable / scalable ?  Seems like we have moved from being enamored with mobile ui (quick apps that don’t necessarily scale) to really making mobility part of a business transformation. I hear from customers all the time that they need to scale and sustain apps across a wide range of use cases as hey move forward.

      love to hear your perspective on this As well as Stephen’s

      pab

      (0) 
    3. Stephen Kringas Post author

      Hi Riley,

      Thanks for providing your valuable insight, especially from someone who has in-depth knowledge of both platforms.


      Do you find many clients developing purely native applications for SMP? I can imagine when you start to target 2 or more platforms (iOS & Android…maybe Windows) the cost of doing so would be very expensive. Cost of resources, maintenance, keeping features as consistent across each platform etc.

      In my experience the “pseudo” native approach provides near native performance and is sufficient for building data driven mobile applications. Plus you have the added benefit of targeting multiple platforms with a single code base (of course with some platform specific logic/UI layer in most cases). Appcelerator does this particularly well with their open source Titanium SDK and Alloy MVC framework.

      As a developer I agree with your assessment of the SMP being more flexible, open and provides greater range of options for building mobile apps.Probably the biggest hurdle that I hear from clients evaluating SMP against other mobile platforms, are the licensing costs. Hopefully the cloud version of SMP will help alleviate this concern.

      Overall I think both platforms have their pros/cons but it’s good to be aware of the different options available for building mobile apps for SAP.

      Thanks,

      Stephen

      (0) 
  4. Suseelan Hari

    Hi Stephen,

    I am hearing first time about KonyOne platform and nice to know that there are three approaches for building mobile applications that integrate with SAP.I am updating my knowledge in SAP SMP too. Already cross training is going on in SAP SUP. Thanks for showing new things and new updates related to Konyone platform. Nice pics and very well documented. Keep up the good work. I thoroughly enjoyed it. I will share this document with my SUP team mates.

    Regards,

    Hari Suseelan

    (0) 
    1. Stephen Kringas Post author

      Hi Adam,

      To my knowledge when developing Kony applications you’ll need to you use the KonyStudio. So in this regard, the SMP offers a lot more flexibility/options for your development workflow/tooling.

      Cheers,

      Stephen

      (0) 
    2. Stephen Kringas Post author

      Hi Adam,

      I stand corrected…..How quickly things change in the Mobile world 🙂 Just letting you know that Kony is now going to offer an MBaaS solution that will allow you to bring your own tooling to the platform – PhoneGap, Sencha Touch, JQuery, native iOS & Android etc.

      Cheers,

      Stephen

      (0) 

Leave a Reply