Overview of MBO application (Before migration)
|MBO iOS App||OData iOS App|
This blog will be the first blog in the iOS migration branch. In this blog, we will take a quick look at a sample MBO application that we will eventually migrate. The sample MBO application is not very complex and is merely used to illustrate the various concepts involved in the migration process. If you are already familiar with the MBO concepts, then you can skip this blog and move to the next one in this series.
This sample MBO based application is implemented as an offline application. The Objective C generated code is used in the creation of the client application. The EPM data model shipped with the SAP Business Suite is used to create the MBOs and the client application.
In SMP 2.3 on-boarding is done via the SUPApplication class and the process is to check to see if the device is registered. If not, an asynchronous registration process is kicked off. There is no prebuilt UI for the on-boarding process. The developer is in charge of creating the UI. This can be as simple as providing textboxes to enter username and password. And that is precisely what our sample MBO application provides as well. Just a simple login page for the user to enter username and password.
Synchronization parameters and synchronizing data
Once on-boarding is complete, the next logical step in the sample MBO application is to synchronize data with the backend. However prior to synchronizing data, the application needs to set the synchronization parameters. You can think of synchronization parameters as filters. It is used to filter the amount of data that is sent down to the device from the consolidated database.
– (void) SetSynchronizationParameters
SUPObjectList *subscriptions = [CentralMBODesignBusinessPartner getSubscriptions];
if ([subscriptions length] > 0)
CentralMBODesignBusinessPartnerSubscription *subscription = (CentralMBODesignBusinessPartnerSubscription *)[subscriptions item:0];
CentralMBODesignBusinessPartnerSubscription *subscription = [CentralMBODesignBusinessPartnerSubscription getInstance];
subscription.SP_Country = @”US”;
This sets the SP_Country sync parameter value to “US”. Basically, only rows with Country = “US” are sent down to the device. Once the sync parameter is set, the synchronize method is called to synchronize the backend data with the device database. Note that synchronize can be called by passing the synchronization group as an argument. Typically, the first time the application calls synchronize, no argument is passed. This means that the entire MBO set on the device is synchronized with backend data. Subsequent synchronization calls pass specific synchronization groups based on screen flow to synchronize select group of MBOs.
Reading data – findAll (Prebuilt queries)
Once synchronization is complete, the sample application reads the data in the device database and displays the data to the user. The data in the device database is stored in an SQLite / UltraLite database depending on the SUP version.
[self setBusinessPartners:(SUPObjectList *)[CentralMBODesignBusinessPartner findAll]];
By default, a findAll object query is generated for every MBO. All rows for the BusinessPartner MBO are returned which is then displayed. Note that the data is read synchronously in MBO Object API. In addition, findAll reads the data of child items as well. This is very important when it comes to migration, since a single call to read the database – ends up reading multiple related tables.
Clicking on any business partner brings up the sales orders associated with that business partner. Since the BusinessPartner MBO is related to the SalesOrder MBO, it is easily retrieved as a property of the BusinessPartner MBO itself. Note that we are not making a separate call to read the SalesOrder table. SalesOrder rows are already available to us, because of the findAll call.
salesOrderViewController.salesOrders = [self selectedBusinessPartner].salesOrders;
Similarly, clicking on any sales order brings up the list of sales order items. Again, we are not making a call to read from the local database.
Reading data – Custom queries
Clicking on the sales order items brings up the product detail screen. Since there is no explicit relationship between sales order items and products defined, we use a custom SQL query to join the tables and retrieve the data to be displayed.
SUPQuery *query = [SUPQuery getInstance];
[query from:@”SalesOrderItems” :@”A”];
[query join:@”Product” :@”B” :@”A.PRODUCT_ID” :@”B.PRODUCT_ID”];
SUPTestCriteria *criteria = query.testCriteria;
criteria = (SUPTestCriteria *)[[SUPAttributeTest match:@”A.SO_ID” :[self orderIDValue]] and:[SUPAttributeTest match:@”A.SO_ITEM_POS” :[self itemIDValue]]];
SUPQueryResultSet *result = [CentralMBODesignCentralMBODesignDB executeQuery:query];
The product details screen now displays data from both SalesOrderItems and Product table by creating a customized SQL statement.
The create method allows the client application to create a new record in the local database. Note that this record only exists in the local database and not on the backend. To submit the changes to the backend, SubmitPending method needs to be called.
BusinessPartner *businessPartner = [[BusinessPartner alloc] init];
businessPartner.BP_ID = @”10000001”;
businessPartner.BP_ROLE = @”3”;
… //Set the required fields for the business partner
The sample MBO application covers some of the basic features like On-boarding, Initial Synchronization, GET operation, CUD operations etc. In the next blog, we will cover all the steps involved in migrating this sample application. In addition, we will also talk about some of the complex features that one would encounter when migrating.
Let the migration process begin!!