cancel
Showing results for 
Search instead for 
Did you mean: 

Sync with conditions

Former Member
0 Kudos

Hi experts!

I would like to know if it is possible to sync Data Objects with conditions from de mobile client to de DOE. Here we have a scenario where the client wants to upload to the backend only orders that are finalized. In our Data Object Node we created an BOOL attribute 'finalized', in the client this status is setted when needed. If the order is not finalized, the changes made on client (such as 'description' and 'hours spent') can´t be lost on close the mobile client and can´t either go to backend until this order is finalized.

I tried to change the BAPI Wrapper modify adding the condition in ABAP code, an example above. On first sync only those finalized were uploaded to backend (and consolidated data store also). On second sync the changes made on non finalized orders on client were lost, overloaded by the backend values.

BAPI Wrapper modify, first try:

IF ( ORDERHEADER-FINALIZED = '1' ).

  UPDATE ZORDER
    SET HOURS_SPENT = ORDERHEADER-HOURS_SPENT
        FINALIZED = ORDERHEADER-FINALIZED
    WHERE ID = ORDERHEADER-ID.

ENDIF.

Please sugestions.

Regards,

Gabriela

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

The results of your first try is the expected behaviour .For all kinds of upload messages from client ,always the latest image of that instance from BE is loaded to DOE and then sent to client.

One thing that could be tried is to send rejections for those messages with non-finalized orders from BE and in the mobile client , you can code in the client application such as to keep client image of the instance (order) when rejections are received.

The flow will be

upload message from client with non-finalized orders> Error message send from BE (fill bapiret2 of bapiwrapper)>inturn rejection will be sent from DOE to mobile client( CDS will have BE image ) --> But Mobile client keeps the client image of this order.

But later when the order is finalized , i dont know how we can send the previously modified fields again of the same order.

I am sure there will be more smart ideas coming in

Liji

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi,

Tanks Liji, Vaidehi and Ramanath for your quick reply!

Those sugestions for temp table creation, duplicate DOs creating local DOs and duplicate DO attributes disabling BE Fields option on DOE, seems to me good solutions but expensive for mobile because increse 2x the storage cost. Our PDA specifications is:

CPU: Marvell PXA270 Processor 312 MHz

Mem: 192 MB ROM and 64 MB SDRAM

SO: Microsoft® Windows Mobileu2122 5.0 for Pocket PC, Premium Edition

The rejection solution seems to be closer to our reality. I found this PDF Rejection Handling NW Mobile 7.1 explaining step by step how to implement on WebDynpro DOE rejections handlers. What kind of changes do I need to make on DOE? Do I need to change BAPI Wrapper modify to throw an exception or to develop a service on standard data flow?

Our mobile infrastructure version is 7.1, Sync BO solution can´t be used anymore, am I right?

Best Regards,

Gabriela

Former Member
0 Kudos

Hi,

This solution will work with NW Mobile 7.1 , not for syncBO solution(7.0 or MI2.5)

My understanding is that it is enough to fill the tables parameter " RETURN" STRUCTURE BAPIRET2 with messagetype 'E' of the bapiwrapper incase of non-finalized orders and the normal flow itself will send a rejection to Mobile client (No need for any custom service). Function Module 'SMGF_FILL_BAPIRET' fills the bapiret by passing the proper error types and message classes. (In a BE system if this FM is present, am not sure..but i guess filling bapiret2 must be a simple thing)

Regards,

Liji

former_member53099
Participant
0 Kudos

Hi,

The facility of a conditional sync is not provided by the client. Whatever is changed and commited through an application will always be converted into a sync message and sent to the DOE in the next sync

Presently your scenario is to send only the finalized DOs to the BE ie an application developer will create an Order instance and save. But this instance will not be conveyed to the DOE. Later this order instance is finalized (the finalized flag is set to true) and then only it needs to be sent to the DOE in the sync.

Possible solution 1

The use of rejection handling in this case will make you choose between

- present client image (which has finalized flag set to false initially)

- server image (which is blank as this instance will be going for the first time)

So as a result your instance will be either stay in inconsistent state(ie not confirmed by DOE) or be deleted(if server image is accepted).

Now one can change the inconsistent state again to finalized = true and sync again. This time the instance will be accepted.

You can refer to the following link to read more about the rejection apis provided

<http://help.sap.com/javadocs/nwmobile/SP1/com/sap/tc/mobile/cfs/mbosync/api/package-summary.html>

Possible solution 2

Storing the non-finalized instances in a temporary location like a DB table and then commit these instance only once the 'finalized' flag is set to true. So in next sync only those instances will be sent to DOE for whom the finalized flag has been set to true.

Possible solution 3

If this is a 7.1 Mobile Webdynpro application then you can create a local data object (which will be a replica of your standard Order data object) Use the local data object in the application to hold/display data. So during sync the content of this will not be sent to the DOE and will stay locally on the device. Once the finalized flag is set to true, only then copy the contents of this Local to the Standard Order DO. In next sync the finalized instances will be sent across

Possible solution 4

If this is a Backward compatible application, then you can make use of the following api 'setSendType'. This is an enumeration of possible Sync BO- out delta sending type. Depending on it the data will be set to value default/send/no send/ send direct.

You can read more about this api at this location

<http://help.sap.com/javadocs/NW04S/SPS09/me/index.html>

Best Regards

Vaidehi

Former Member
0 Kudos

Hi,

Here is another way of achiving the same functionality.

The root cause of the problem you are facing is the fact that the attributes in the data object node are mapped as BE Fields i.e. Backend Fields. Hence if the record is not satisfying the necessary condition (in your case, Finalized = 1), then the instance would be rejected and hence all the fields will be reverted to the original backend image.

To resolve this, you can have additional fields in the data object node which will not be BE fields. So even if the record is being rejected by backend, these fields will continue to have the same value which client has sent. Your bapi wrapper can have the logic of copying these fields into the correpsonding fields of the backend if the necessary condition is satisfied.

~ cheers,

Ramanath.