There are a number of valid ways to integrate SAP into a mobile environment, and the best approach will depend greatly on the business and application requirements. For example, a company wishing to optimize performance may wish to architect a staging database approach that implements the .NET or Java APIs for SAP. Other companies looking to extend their current investment in NetWeaver may wish to architect a solution based on Web Services or using enterprise messaging infrastructure.
Regardless of the architecture selected, a mobile database product, such as SQL Anywhere, can provide a variety of options to bring your SAP data into a truly scalable and secure mobile platform.
SQL Anywhere
SQL Anywhere is a suite of data management and data exchange technologies and their related design and management tools. Traditionally, the product has offered database synchronization as its primary technology for data exchange. However, over the last two releases, SQL Anywhere has been extended to include the mobilization of Web Services and enterprise messaging sources. Together these technologies provide four primary integration options:
- Database synchronization: A bi-directional exchange of information between remote SQL Anywhere databases and a variety of databases within the enterprise, including SQL Anywhere Server, Sybase Adaptive Server Enterprise, Oracle, Microsoft SQL Server, and IBM DB2.
- Java Message Service (JMS): Allows access to data within application servers such as WebLogic and JBoss, enterprise messaging environments such as WebSphere MQ and MSMQ, and other systems like SAP and TIBCO.
- Web Services: A popular way to standardize the interoperation of enterprise applications by extending data to mobile architectures through Web Services in SQL Anywhere.
- Synchronization API: Allows developers to create custom interfaces to any kind of data source.
Recently, SAP has been transitioning to a new architectural platform called NetWeaver. NetWeaver provides a service-oriented application and integration platform for each of the current SAP business applications. Within the NetWeaver application server, there are a number of components that provide standard interfaces to an SAP back-end system. Two of the most important components offered within NetWeaver are:
- SAP Web Application Server: Provides support for Web Services; based on technologies such as J2EE and ABAP.
- SAP Exchange Infrastructure (XI): Based on general messaging standards that enable external systems to be integrated via interfaces such as JMS; XI offers both synchronous and asynchronous interfaces.
Integration Approaches
There are several viable options for integrating SAP using mobile application architecture. Most integrate directly into NetWeaver. Many of them provide direct access to SAP via .NET and Java APIs available within SQL Anywhere.
Using the Web Application Server component of NetWeaver yields one of the simplest forms of integration with SAP. Within the Web Application Server, Web Services are consumed by the SQL Anywhere MobiLink server to upload and download information to and from the mobile clients. In this scenario the MobiLink server resides within the corporate firewall and provides encryption, compression, and user authentication and secures data access.
To expand on this architecture, SQL Anywhere has the ability to ''prioritize'' data synchronization. For example, a company may decide that product and inventory data is a priority and must be downloaded during each synchronization, whereas sales results are less important and should be downloaded less frequently. This architecture allows a developer to define rules that determine which set of data is required at any one time, effectively reducing server-processing requirements within NetWeaver and SAP.
A second architecture involves a combination of Web Services and enterprise messaging. As we can see in the above diagram, Web Services provide the user with real-time access to SAP data. Information uploaded from the device to the server will use the messaging infrastructure. Sometimes, it is more important to have real-time access to downloaded data, while data uploaded from the client is less time critical, which makes queuing information for upload to SAP acceptable. This architecture’s major advantage is that it offloads the processing requirements of NetWeaver and the SAP system. The diagram below shows bi-directional access to SAP using both Web Services and the messaging infrastructure through the MobiLink server.
While uploading and downloading information to a mobile device using the SAP Web Application Server is a viable way to mobilize SAP, performance and scalability can be a problem. The number of concurrent synchronizations at any one time will grow proportionate to the number of mobile users. This may have an impact on how quickly information can be generated and sent to the MobiLink server. Therefore, a staging database approach to SAP integration may be appropriate.
With a staging database specific pieces of information from SAP are stored within a relational database. Upon synchronization the information downloaded comes directly from the staging database; NetWeaver and the SAP system are not used, reducing resource requirements on the server. An administrator can also use business rules to determine when the staging database is refreshed.
The main disadvantage to a staging database is that a user may not know that the information synchronized is real-time. Based on how long it takes to refresh the staging database, there will be some period of time when the information becomes ''stale.'' With priority synchronization, however, we are able to determine what data needs to be real-time and what data can be less up-to-date: high-priority information can be received directly from SAP via NetWeaver, while less important information can be downloaded via the staging database. The advantages:
- Work can be offloaded from the NetWeaver/SAP systems.
- Critical data can be downloaded in a real-time mode.
- The staging database will include less critical data only.
- Synchronization performance is optimized based on business requirements.
Sometimes, moving to a NetWeaver environment is not the best option for customers looking to mobilize SAP data. Furthermore, Web Services may not be the most efficient means of providing data to the mobile client. Since there is significant overhead associated with creating the XML document and transferring it over the network, it may be wise to consider an option that allows SQL Anywhere direct access to SAP via the more efficient means of .NET or Java connectors.
In many cases customers who have made an investment in NetWeaver will want to keep their business logic where it is; however, for those who have not yet deployed NetWeaver, using the connector access to SAP is a good alternative.
As shown in the above diagram, this is the simplest architecture option and requires very few components to move data back and forth. Since a NetWeaver application server is not involved, XML translation is not required, making the connector access an extremely efficient means of transferring information to and from the MobiLink server. However, the main downside is that users will have to wait for SAP to serve up data before they can download information to their mobile devices. For this reason a staging database approach may be worth considering.
This architecture still has the advantage of being able to retrieve information from SAP via Java or .NET connectors quickly while still optimizing synchronization from a mobile user perspective. The disadvantage to this solution is that the information stored in the staging database is duplicated and may only be as up-to-date as the last time it was refreshed from SAP. For this reason we can also consider using priority synchronization to create a hybrid staging-direct access architecture.
Using priority synchronization, information deemed critical can be accessed directly via SAP. However, information deemed less critical can be retrieved via the staging database to give the user the ultimate flexibility from a performance perspective.
Issues to Consider
Regardless of the architecture that is chosen, there are a number of issues that will need to be considered before implementation. A couple of these issues are:
- Change detection: If you are not using a staging database, the Web Services or enterprise messaging infrastructure will need a way to determine what has changed from one synchronization to another. SQL Anywhere maintains this information. However, it will be important to then take this information and implement it into the web service to limit the data downloaded to the device.
- Conflict detection and resolution: In a traditional synchronization environment, SQL Anywhere has direct access to the central data store and thus has the ability to detect and resolve conflicts automatically. However, in a NetWeaver environment, SQL Anywhere does not have direct access to the data. Therefore, it is the job of the NetWeaver logic to ensure that data is applied correctly and to report back to the MobiLink server any issues, such as failed updates or conflicts.
