Why SMP and Why Not
Hi,
Recently, i was exploring few options for a giving up a solution architecture to one of my customers who needs a mobile solution which gets synchronized with their SAP back-end system. So i just thought to Blog it for my friends out here and i end up figuring out that there are two major ways for doing this 😕 i.e,
- Using SMP (SAP Mobile Platform)
- Using JCo (Java Connector) i.e, without SMP.
So here are the advantages i figured out for both the approaches:-
Using SMP:
- There are Native(Object API, ODATA) and Hybrid application(Html5 based) development approches. The platfrom provides you to develop Hybrid applications easily by drag and drop.
- You can integrate various backend systems easily so that you handle connectivity of systems.
- Be able to create offline scenarios with SUP platform. (Native development)
- You can model your data by creating relations, queries etc.. (MBO development)
- Manage and monitor device users acitivity on Sybase Control Center
- Enable you to configure SSO or Active directory.
- Provides end to end security
Using JCo (Without SMP)
- With Jco you can direclty access to RFC without using web services
- Create only online scenarious.
- You have to make development for each device(ios, android, win8)
That’s all till now i figured out.
However this is an interesting question and if I understand it correctly we are basically trying to understand here whether to use a middleware like SUP/SMP or not or perhaps just use another middleware?
The question can only be answered through some analysis of requirements topics like the following should point towards whether we should be using SUP/SMP or not:
Security
- How sensitive is the data you are planning to mobilise and do you need the extra security mechanisms that SUP/SMP brings 😕 ?
- How do you plan on authenticating your users and will you be able to do that in a large scale roll-out without a box like SUP/SMP in the middle.
- Do you require on-device security enhancements to protect the data you transmit to a device.
- Synchronisation
- Are you planning on synchronising and storing data on the mobile devices and if so have you considered how that sync will happen without a middleware to manage the sync process.
- How do you plan on achieving the synchronisation between your devices and the back-end server (protocols, packaging, parsing etc.)
Synchronization
- Are you planning on synchronizing and storing data on the mobile devices and if so have you considered how that sync will happen without a middleware to manage the sync process.
- How do you plan on achieving the synchronisation between your devices and the back-end server (protocols, packaging, parsing etc.)
Device management
- Do you need the connection/device management brought by SUP/SMP
There are a lot of topics we would need to look at before we can make a decision on this and we will not be able to get a clear answer here without completely understanding the requirements and what we need to achieve. Its also worth looking at how we have delivered other applications (if we have) in your environment including what worked/did not.
I still falls into this scenario again & again while proposing a solution to customers & always exploring the right solution for it. However, i’d always like say Thanks 🙂 to few of my friends out here for always helping me out here like Midhun VP , Jitendra Kansal , Tahir Oz, Brenton O’Callaghan , Carolyn Coad , David Clavey , Rohith Deraje , Kevin Benedict , Thomas Jung
Off course there are other workarounds also available & i’d appreciate if you folks will provide light on this here below 🙂
Best Regards,
Good One Shrikant ..
Every time we get new requirement, we explore new solutions...
It is good experience to get into the requirement deeply, and find out the exact solution and propose it.....
Regards
Shrutika Purohit
Thanks Shrutika Purohit 🙂 .
Agree with U.
There is a big complexity while mobilizing the enterprise. SMP is meant to make the process easy and secured. Few of the advantages of using SMP when compared without a middle-ware are:
Apart from the above we don't want to bother about the security, logging, tracing, SSO ( in few steps ).
So these are the reason to go with SMP/middle-ware.
Recently SAP released apps based on SAPUI5 ( FIORI series ) and it is not based on SMP. Again, these apps are based on web technologies hence the performance we can't expect as good as native apps.
Finally, selection of development approach is purely based on the available resource and business requirement. If the company is planning to go mobile and the budget is low means they can mobilize there process with NW gateway. They don;t need to spend on SMP. So selection of a technology is based on the above factors and SAP is providing us the completing set of solutions from which we can select a solution.
-Midhun VP
Yes exactly Midhun. Correct solution depends on such factors & that is why now SAP is providing the range of solutions & approaches to develop. However it completely depends on our requirement which solution to choose.
But here i'd like to add that from 3.0 SAP is most likely to change lot of things. As far as i know SAP is looking for much tighter integration with Netweaver Gateway & also they will be providing the Offline Capabilities through the ODATA channel as well.
So it will help us to propose/choose the right approach more easily.
- Shrikant
I would have a look at how the Fiori apps are created and add it to your second non-SMP list. The big point about Fiori is that it uses ODATA via the Netweaver Gateway. So all the security and data change is based on the Gateway.
I would not create a mobile app using JCO - Old technology. It will work fine, especially if you are a Java on mobile fan. But Java on a mobile is all too slow and jerky for me and crashes randomly ! You can guess I am not a fan.
So I would modify your two options to SMP and Netweaver Gateway.
Integrated SAP Netweaver Gateway & SMP can always provide GREAT solutions. And after SMP3.0 this integration along with ODATA will provide the much more benefits as Offline capability is expected to be coming in that which is a miss in current scenario.
But David, here again we are gonna face the "How can I help you" scenario when the customers are not interested in buying SMP licenses & wants the mobile solutions directly based on Netweaver Gateway beacuse i Gateway licenses comes handy with their current licensing landscape & used to be available with them already.
-Shrikant.
You should have a look into the SMP Cloud version as well. Initial investment is low. Setup of the Cloud connector and configuration of the SMP can be done in a day. The REST services are the same as in the on-premise version as well.
Wrote a blog about the pros of this solution here
Very Informative...Many Thanks.
Best Regards,
Naresh K.
Great guys!!
At the end of the day, the solution should be satisfied all customers need.
Possibly will be SMP, Netweaver, Syclo, Consumer app, Ready to deploy app etc...
The Main challenge is to get the customer satisfy with the right solution on right time.
Lot many things are there is SAP BOX .....
Shrutika P
Shrikant Naidu
Thanks for mentioning my name. 😀
you have summerized all possible points in a single blog. really helpful. 🙂
Rgrds,
Jitendra
Very Informative...
ll give a picture that what to use at what time..
Thanks...:)
Very Informative. Great Job Shrikant Naidu
Thanks,
Rama
Hi Shrikant,
Very interesting topic and at the same time challenging for the people at the field. Here is my list of options and we can propose based on the pulse of the customer. Are they looking for quick wins?
1. Point Solution – Expose SAP transactions through webservices and consume in the mobile devices, Native, SAP UI 5( including Fiori customization)
2. Use open source framework/tools
Open platform that leverages 3rd party HTML5/JavaScript/Native Libraries such as Sencha Touch/JQuery Mobile as well as custom developed libraries
3. Use development platform/ Cross platform development tools
Appcelerator
Rhomobile
Xamarin
4. Middleware development tool
SAP Mobile Platform
Sybase Unwired Platform
Syclo
It is important to have a mobile strategy and roadmap by considering the following:
Business and IT objectives
Current and future business processes
Business impact
Cost
Rugged feature assessment
Mobile connectivity and security
Backend infrastructure
User segmentation
Mobile device/Network evaluation
MDM/MEAP evaluation
Payback period analysis
Finally it is all about transformational journey through the four phases: Mobilization, Enhancement, Reshapement and Redefinition. You may not get it right for the first time!
Good luck with your proposal.
-Nixon
Very True Nixon Xavier & agree with you completely in this aspect.
Thanks for elaborating your thoughts on this.
However the tools available today gives the ability to tailor the customer's need, the win depends upon the customer's take on their Enterprise Mobility investment & the belief on the technology/architecture we propose 😉 .
-Shrikant.
Only 2? There are more. Why did you add JCo? Have you actually tried to understand the mobile options in general and from SAP before coming to the above conclusion?
Just for completeness, I will point out that the (Syclo) Agentry platform, which works both independent of or within SMP 2.3 and above, uses JCo as the integration mechanism with the SAP ERP backend. It is very stable and as Agentry is by design a default offline architecture, is not so sensitive to the limitations mentioned for JCo.
Regards, Mike
Rapid Innovation Group - RIG
All the "points" and "issues" regarding JCo are just not true as JCo is being put in a context here that makes no sense. JCo shouldn't even be in the list. When are you doing an iOS mobile app with JCo? JCo will always be invoked by a platform that is between the mobile device and the ABAP backend, be it Syclo, SUP, Portal or something else.
HI Tobias,
Like your points.
I have always had good success and better performance from JCo (BAPI/RFC) than web services. Not sure about other implementation scenarios, but in my experience JCo is simply a Java Connector between two systems/endpoints. How well it works depends on many other factors (network, anybody?), including what you are passing back and forth.
SMP/SUP information provided by you is very useful. thanks srikanth.
Hi,
Note :(The views expressed in this are strictly based on my opinion/experience in various SAP projects )
For SAP Customers in various industries like Utilities who are looking to Mobilize their
field workers ,Syclo would be the good option from Architecture point of view .
Here are my thoughts lets say we have a third party Mobile solution who would want to mobilize the field workers of an SAP Customer ,then one of the traditional approach would be using the SAP middleware solution like SAPXI/PI .
In this case SAP ECC/CRM ->SAP PI-> Third party mobile product and
Third party solution -> SAP PI -> SAP ECC/CRM etc....
In this case enhancements/new field additions would take much more time for development which would be an additional cost to the SAP Customer .
Incase of Syclo the time taken would be less for same enhancement and the greatest advantage of Syclo is its ""Addon component "" ,this tighter integration differentiates SAP/Syclo from other third party Mobile product. And more over the Syclo mobile suite has good GIS integration capabilities and much more (3D Visualization Capability of (Right hemisphere),Acquired by SAP).
(As michael Appleby mentioned Syclo uses JCo as the integration mechanism with the SAP ERP backend)
I personally worked on a utility project that integrated with SAP ECC backend using SAP PI with Third party Product and believe me it was a great pain for enhancements/field additions in reimporting the IDOC/RFC that was enhanced and then mapping those again in SAP PI and making the required changes in Third party product.
Thanks,
Pradeep.
Hi Shrikant,
I need clarification for when you say Using JCO (Without SMP). Do you mean SMP does not allow us to use JCO? As per my knowledge, you can use JCO with SMP and it gives really fast connectivity for data communication between SMP and backend system.
Affaan
That's correct, SUP for sure supports JCo, but his message is "using jco without SMP" what means you can use JCo yourself to implement a mobile solution without using Syclo or Sybase Unwired Platform.
So the hole work done by Syclo and Sybase is up to you, you got the possibility to use JCo as connection to your backend.
Hi Shrikant,
Excellent Blog
There is indeed another third option SAP with Kony(Sky Add-in)
You can install SAP Certified SKY add-in into your ECC and connect your device to ECC.
This is real exciting way for people who want to control mobile from ECC systems
More details are here....
http://www.kony.com/products/development/sap
If you need more info I am more than happy to help
Regards
Vivek Nidhi
Shrikant,
The article is very informative. Thanks.
My question is - Can we use SMP for non-SAP applications/functions ? My client is trying to know if they need to maintain two mobility infrastructures ?
Gopi
Hi Gopi,
I heard something about Gateway Java.
With Gateway Java, now non-SAP data can be OData enabled. you can check it.
Rgrds,
Jitendra
Gateway Java is now called "Integration Gateway" I believe ....
Yes its possible to connect SMP with heterogeneous data sources like SAP, Microsoft, MySQL, Web services, REST webservices etc. It is one of the advantage of using SMP as a solution. It supports heterogeneous Databases and devices.
- Midhun VP
Thanks, looks like SMP is the way to go 🙂