Offline capabilities and SOAP integration

Offline capabilities and SOAP integration

  

Hello,

i've been trying to build an application with offline capabilities and i've run into a question.

In this case, we have a SOAP service which contains all the methods for creating, updating, etc, and every interaction with the database should be done by methods specified in the WSDL of the service.

from what i've gathered a DB and a local storage entity is created for offline while the sync methods update the DB. You affect the local storage and upon having internet connection you can set it up so that the DB entity is updated from the local storage entity. That's perfect really and kudos on the way you made this but what if there is no entity representing the DB? 

in my personal case i want to store some data locally for offline usage but everytime the sync happens, the methods provided by the service should be the ones used to update the DB. It's worth noting that setting up the SOAP as a consumable service has created a bunch of structures.

so, how can i implement my application in the scope of being able to make the most of the Offline Sync methods that Outsystems 10 provides, while having to use the service for DB interactions?

do i have to change the logic of the existing offline sync actions to specifically call the methods from the service that i want?

should i expose the structures as entities and outsystems automatically calls the service method associated with the structure?

Best Regards,

Bruno Gonçalves

Solution

Hi Bruno,

When it's time to sync, check the local database for what needs to be synced and call the SOAP service to store the data. You can directly call the SOAP service from the OfflineDataSync local action, or pass the data to a server action that calls the SOAP service, depending on your needs.

Solution

Hi Kilian,

thanks for the reply, i got it going now! 

Best Regards,

Bruno Gonçalves

Hi Bruno, good to hear!

Hi Bruno,

Very interesting question and use case.

The first thing you need to do when designing an offline app is to identify what use cases need to work with the app offline and what data do you need to store in the device and how will you access it: read-only, read /write. Having the database as a source of data in the server is the most common use case and offline data sync actions help you keep local storage and database in sync.

In your scenario the source of "online" data are a set of SOAP web service methods. Reusing or adapting offline data sync actions that deal with database is possible, but doing it from scratch would be easier. The main reason is that SOAP web services expose totally different APIs and capabilities than the one exposed by database entities.

Here are a few pointers for your to move next:

1. Define the local storage model

The first step is to determine what data you need to store in local storage. Remember that the local storage is the only source that your application will have to gather data once once it is offline. Here it is a lot of database modeling work, and be sure to keep just what you need for your offline operation.

2. Setup synchronization

The synchronization logic depends on the how your app will access the data - whether your app is going to just read data in offline or if it also allows modifications to data.

2.1 Setup a Read-only data sync

If you just need to read data while in offline, it is quite simple to setup the synchronization. All you have to do is to create a server action that calls the SOAP web service to gather data, and use in a client action that updates all the data in local storage.

This documentation topic describes this read-only data pattern. The difference is that instead of having an aggregate to fetch data in the database you will have to call your SOAP web service methods to retrieve data.

2.2. Setup a Read/Write data sync

If your app needs to both read and modify data, a more complex pattern is needed. The server action will need to call SOAP web service methods to update data, and others to retrieve data. The client action will have to send all local changes in the local storage to the server, and receive and update the newest changes from the server.

This documentation pattern describes the most simple of these patterns, where the last writer wins. Again the difference is that in the server action you will have SOAP web service methods to modify and retrieve data, instead of the entity actions and aggregates.

3. Wrap it up

Finally you can put these synchronization actions in the OfflineDataSync action, as described in the documentation.


Tell us if it worked!