SAP is like an ocean by itself covering all the various aspects of an organization. It is also one of the most difficult systems to integrate with its variety of native, proprietary APIs from RFC (Remote Function Calls), BAPI (Business Application Programming Interface), IDoc (Interchange Documents), and more.
We all know that ERP, CRM, Supply-Chain applications, etc. were never really designed for mobile consumption. SAP Applications are certainly no exceptions. As a result, mobile enabling SAP applications can be a laborious and time-consuming task.
Sure, there are a lot of mobile development platforms that promise rapid development and do a good job in compressing the mobile app development process. Some even give a graphical drag-n-drop IDE that makes it easy to develop mobile apps. However, all the mobile development platforms assume that SAP API’s are already available and provide the right data for mobile consumption.
Exposing the Right Data With SAP’s API
However, while mobilizing SAP applications, most of the effort is spent in exposing the right SAP data with the right business rules behind it, for the mobile app to consume. Depending on the mobile app to be developed and the mobile app development platform used, between 30-70 percent of the development effort can be spent on the SAP side.
Also, consider the fact that a large percentage of the SAP code, like standard function modules and report programs, are never exposed as an API by SAP. Furthermore, SAP is usually customized with “Z” programs to meet the specific needs of the business. Most of these custom “Z” programs were not developed to be an API (E.g. RFC) in the first place. As a result, if a developer wants to leverage existing business rules and expose any non-remote enabled programs for mobile consumption, the only way to do it would be to write some wrapper programs (RFCs) around these non-remote enabled programs to expose the data.
If some of these non-remote enabled programs are custom “Z” programs, the developer has to write custom wrapper programs on top of custom programs to expose the data. This in and of itself adds to the development time. Additionally, customization on top of customization creates a headache for maintenance and upgrades.
Is it Really That Complex?
So, if this is all so complex, why do some mobility vendors promise quick mobile deployment : in a matter of weeks? It is because the mobile development platforms compress the development cycle within their platform. However, they do not talk about what it takes to provide the right data for mobile consumption.
SAP has approached this problem with its NetWeaver Gateway product. It generates ODATA Services from SAP RFC/BAPI, etc. for SAP’s Mobile Platform, as well as for other mobile platforms including iOS and Android to consume.
However, NetWeaver Gateway is restricted again by SAP API’s. In other words, NetWeaver Gateway needs an RFC or BAPI in place to generate ODATA Service. So even with this solution, the critical bottleneck becomes : what are the API’s exposed by SAP? And for the programs that are not exposed, the developer has to write custom wrapper programs to make it an RFC even before NetWeaver Gateway can consume it.
The appsFreedom Solution
Here at appsFreedom, we always felt restricted and limited by the SAP APIs and have worked hard to break the SAP API Barrier. We have accomplished this with the Freedom Platform, which is the only platform today that can discover any SAP asset and meta data. This includes non-remote enabled function modules, custom “Z” function modules, and custom “Z” programs while generating services on the fly without the ABAP developer having to explicitly log into SAP.
The Integration Builder, which is module built into the appsFreedom Platform, discovers all non-remote and “Z” programs and lets the developer map the data from SAP to mobile apps without having to first generate a service. The appsFreedom platform does all the work behind the scenes, transparent to the developer. Best of all, the appsFreedom platform resides in the cloud, allowing the SAP programmer to consume any SAP program from the cloud, thus breaking the SAP API barrier.
The appsFreedom Platform promises a soup-to-nuts mobile app enablement in two to four weeks, and unlike other mobile vendors that talk about rapid development within their platform but leave the SAP API enablement to the customer, the appsFreedom Platform’s rapid deployment includes everything from prototyping to collaboration and back-end integration along with SAP API enablement, including “Z” programs and app deployment.
Sound unbelievable? We think you’ll find it truly amazing, and we encourage you to see it in action. Contact us today for a demo.