OData iOS Content:
When working offline, all CUD operations are made on the local database. These operations are then queued up to be executed against the backend. When the flush method is called, all the queued operations are executed against the backend. This is very similar to how the MBO Object API and the harmonized OData SDK works. We have already implemented a class in our migration project that deals with opening the Offline Store and performing flush and refresh methods. So at this moment, we can only focus on performing CUD operations against the local database for the entitysets.
CUD operations in the MBO Object API
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. SubmitPending merely queues up the operation to be sent to the backend. The synchronize method submits the local changes to the backend AND brings down changes made to the backend.
BusinessPartner *businessPartner = [[BusinessPartner alloc] init]; businessPartner.BP_ID = @”10000001”; businessPartner.BP_ROLE = @”3”; ... //Set the required fields for the business partner [businessPartner create]; [businessPartner submitPending]; [CentralMBODesignCentralMBODesignDB synchronize]; |
There are different options when it comes to invoking the submitPending method in MBO Object API. It is however recommended to use the submitPending API with the MBO instance – since the other submitPending operations might be expensive.
CUD operations in the harmonized OData SDK
In the MBO Object API, the synchronize method submits all local changes to the backend and the backend changes are sent down to the device. However, in the harmonized OData SDK, this synchronize operation is broken down into 2 parts. The flush method sends all the local changes made on the device to the backend. The refresh method brings down changes made to the backend to the device. The flush and refresh methods requires network connectivity before it can be successfully called.
The process of creating a local entity follows the same pattern as the read operation. Since creating a local entity is common for all entitysets (BUSINESSPARTNER, SALESORDER etc.), we can have a base class that provides all the implementation details. The base class EntityCollection implements the createOperation method. The base class is also responsible for implementing the callbacks associated with the createOperation. In the harmonized OData SDK, the scheduleCreateEntity method is used to create a local entity. Even though it is creating an entity in the local database, this method is still asynchronous in nature.
- (void)createOperation:(id<SODataEntity>)entity forCollection:(NSString *)collectionPath withCompletion:(void(^)(id<SODataEntitySet> entities, id<SODataRequestExecution>requestExecution, NSError *error))completion { self.createObserver = [[NSNotificationCenter defaultCenter] addObserverForName:kCreateOperationFinished object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification *notification) { id<SODataRequestExecution>requestExecution = notification.object; completion(nil, requestExecution, nil); }]; id<SODataRequestExecution> requestExecution = [[ODataContext getStore] scheduleCreateEntity:entity collectionPath:collectionPath delegate:self options:nil]; requestExecution.request.customTag = @"CreateCollection"; } - (void) requestFinished:(id<SODataRequestExecution>)requestExecution { if ([requestExecution.request.customTag isEqualToString:@"CreateCollection"]) { [[NSNotificationCenter defaultCenter] postNotificationName:kCreateOperationFinished object:requestExecution]; [[NSNotificationCenter defaultCenter] removeObserver:self.createObserver]; } } |
UI changes
The UI should not change much for the create operation. The underlying code will change however. In the MBO Object API, an instance of the MBO is created with the values from the UI controls. In the harmonized OData SDK, you will create a SODataEntityDefault object with the values from the UI controls.
self.properties = [NSMutableArray array]; id<SODataProperty> prop = [[SODataPropertyDefault alloc] initWithName:@"BpID"]; prop.value = self.bpIDInput.text; [self.properties addObject:prop]; ... //Set all the required fields for the business partner SODataEntityDefault* entity = [[SODataEntityDefault alloc] initWithType:@"Z_EPM_RKT_SRV.BusinessPartner"]; for (id<SODataProperty> prop in self.properties) { [entity.properties setObject:prop forKey:prop.name]; } [[BUSINESSPARTNER shared]create:entity]; |
Other CUD operations
Update and Delete operations follow the same path as well. The UI controls will not change for these operations. So duplicating the UI code in the migrated project is fine. The code behind will change. The base class is in charge of doing the actual update and delete operation by calling the scheduleUpdate and scheduleDelete methods.
I have attached a sample application that performs CUD operations against the local database using the steps outlined above. Please let me know if you have any questions.
