Watch it at Pluralsight
Introduction
In the first part, we already built a ProjectRanker app for iOS Tablet and Android Smartphone. Now, I’ll show you how to change our current solution for using more tools but less code without affecting the user experience.
First, I am going to show you a second architecture as an alternative to our first approach. This architecture uses more tools proposed by SAP for reducing the need of custom development in connecting your SAP landscape to mobile devices. This course enables you to evaluate SAP tools through the example of the ProjectRanker project.
I discuss the following technologies in the course:
- I will show you how to prepare SAP Business Warehouse as a backend system for mobile projects.
- You will be able to answer questions why to use OData and how to introduce it in SAP mobile projects.
-
You will have a general understanding about the role of the SAP Netweaver Gateway that revolutionize the SAP backend systems for mobile communications.
-
I will be also answering why SAP recommends the SAP Mobile Platform and how it fits into this big picture.
-
Last year, Xamarin and SAP announced their partnership and SAP SDK for SAP Mobile Platform was born. You will see, how can we change an already working Xamarin solution by replacing the job of data collection to SAP SDK without having any side effects on the user experience.
You will see many examples and a ready-to-use app that works with SAP backend systems, so you will get a picture about the implementation details of such a project.
Who is this course for?
This course covers many tools and technologies from SAP and Xamarin. Please take this course as a journey that gives you an insight about the opportunities for SAP mobile projects implemented with Xamarin.
I highly recommend this course for
- SAP mobile project members who need a general understanding how the different pieces fit together.
- SAP professionals of SAP backend systems who want to benefit from the recommended architecture in the course.
- C# developers
who want to understand how SAP SDK works with the backend systems.
I hope this course helps you find orientation and gives information for your SAP mobile projects.
Introduction
In our previous post we have introduced our project idea about creating SAP MM on Mobile with Xamarin platform. In this post we go a little bit deeper and analyze the process of the Goods Receipt and create a mobile wireframe for supporting this process. Let's see how a simple Goods Receipt works based on a Purchase Order.
Mobile Workflow
We found 5 important steps in the workflow of creating a Goods Receipt. We want to support this process with our app:
- 1. Sign In
- 2. Check Open Purchase Orders
- 3. Open a Purchase Order for the Current Delivery
- 4. Check and Confirm the Items
- 5. Send Goods Receipt
We associated a mobile screen for each step and we created a wireframe that shows our idea how we would like to help the work of the colleagues in the warehouse.
1. Sign In
If we want to work with an app that connects to SAP then we want to secure our data. The most obvious part of the mobile security that we authenticate to SAP with our SAP user and password.
2. Check Open Purchase Orders
If a vendor arrives with the delivery to the warehouse, we need to find the Open Purchase Order for the Vendor that we have expected for today. We need a list of the current purchase orders that we can easily associate with the vendor.
3. Open a Purchase Order for the Current Delivery
After finding the appropriate purchase order we can check it's details. Our task is to check and confirm the quantities of the materials on each line item. We need a simple list of items that we can confirm. We want to enter into each line item and close them. The screen below shows a state where we have already checked and confirmed the items, so they are closed. We want to use green color for showing that the confirmed quantity is the same as the quantity on the purchase order and we want to use yellow color if the confirmed quantity is different.
4. Check and Confirm the Items
The main reason of the Goods Receipt's process that we want to check the quantities of the delivered items and confirm the Purchase Order. We want to register the actual received quantities from the Vendor and to close the confirmation process for the current line item.
5. Send Goods Receipt
After we checked each item and saved the confirmed quantities for them, we can close the process by sending the Goods Receipt Document that we have created based on the open Purchase Order. The screenshot shows the final state: the purchase order is deleted from the list and we receive a message from SAP about the successful creation of the Goods Receipt.
Summary
In this post we went through the Goods Receipt process analysis and we created a wireframe. All of the screen elements have a role. During our analyses we made choices what is important for the process and what is not important. The screens resonate with our intent how we want to support it and what are the crucial pieces of information we need for an efficient Goods Receipt.
In the coming post we are going to work on our development based on the prepared wireframe starting with Xamarin Studio. Stay tuned!
Overview
If we want to connect our SAP data to mobile platforms we need to plan our interface carefully. Now, I am going to discuss the mobile integration options and my preferences for SAP Business Warehouse. SAP Business Warehouse is SAP's main backend system for reporting and until now it was not easy at all to connect the main reporting objects, BW queries to mobile. Although we can create BW queries very fast and they are very easy to use, the result behind the scenes is not so simple as we think. A BW Query is not directly connected to the underlying database but it's a logic generated with ABAP and consuming its interface is heavy for mobile scenarios. For many years, we could access and run BW Queries only with OLE DB for OLAP that allowed us to run MDX on the top of XML for Analyses interface so we had to write MDX and the resulting structure was an in-memory infocube instead of a simple table that is quiet challenging to convert to a simple table.
If you look at the screenshot from the Query Designer, you can see that from SAP BW verison 7.3 on we can use Easy Query with SOAP and ODATA that are optimized for mobile devices. In a short period of time we got 2 possible approaches for mobile integration, that is very good, but which method is the best one ? I think it’s worth to analyze the context and driving factors that help us to decide which approach is appropriate for us.
Characteristics
I have collected some characteristics that we can compare and that helped me to set my preference of choice between the 2 mobile options.
SAP Netweaver Gateway
The main driving factor of our choice is the existence of SAP Netweaver Gateway. Easy Query with SOAP doesn’t need any additional components installed for your default SAP Business Warehouse setup, you can use this approach immediately. If you want to use ODATA, you need to add SAP Netweaver Gateway to your system landscape.
Mobile interface
Compared to other interface approaches, both Easy Query and ODATA are for lightweight, mobile consumption. Both approaches support simple BW queries to lightweight consumption providing a simple table interface. This is a great benefit because it’s not easy to read BW queries since they are generated ABAP programs at the back end side working on a star schema and not on a single table. Easy Query and ODATA do the hard job of converting a complex database schema to a simple table.
Query Features
If we take a look at the Query Features, we can see a big difference:
Query Features like “Sorting, Filtering, conditions, paging” are not supported by Easy Query with SOAP. The chance that you need to write custom Function Modules in ABAP is much higher, because you might need to create a simple TOP list for example. So using Easy Query might result in higher development cost compared to ODATA. ODATA supports all of these features out-of-the-box so the chance you need to write custom logic is very low.
Service Maintenance Cost
Service maintenance cost is also higher with the Easy Query with SOAP, because we need to generate and maintain the SOAP service manually on the top of our custom function module, but the ODATA approach generates the necessary models for our service we need only to publish the generated service.
Conclusion
So to sum up my analyses, if you have SAP Netweaver Gateway or you can install it, I recommend using ODATA, otherwise use Easy Query and Custom Function Modules.