mWO synchronisation error

Hi Kapila ,

It’s APP10 UPD10, production environment.

The issue occurs for some of users - 20-30% of them, including IFSAPP

I can see in package MOBILE_TRANSACTION_PUBLISH_SYS in procedure Distribute_Transactions___ that there are 2 inserts to mobile_out_message_tab but that means, that in both inserts there have to be same values which violates standard index

create unique index MOBILE_OUT_MESSAGE_DATA_UIX on MOBILE_OUT_MESSAGE_DATA_TAB (DEVICE_ID, USER_ID, TRANSACTION_SCN, TRANSACTION_MESSAGE_ID);

The problem appears from time to time so I’m looking for clue and solution. 

It’s very problematic for affected users - they are far from company doing their service tasks and have to register work, time and materials on tablets during their work at customer’s customer.

Best regards,

Hubert

Hi Kapila,

Thank you for your answer.

Yes, your are right, there is only one insert into mobile_out_message_data_tab in the procedure Distribute_Transactions___
So it means, that there had to be duplicated data which violated index

   -- Distribute to active devices (called from Publish_One_Transaction_ and Distribute_Init_Transaction_)
   --
   INSERT INTO mobile_out_message_data_tab(device_id, user_id, transaction_scn, transaction_message_id, table_name, transaction_type, message_size)
   SELECT D.device_id, D.user_id, D.transaction_scn, M.transaction_message_id,
          E.table_name,
          decode(M.dml_event_db, DB_DELETE, 'DELETE', DB_UPDATE, 'UPDATE', DB_INSERT, 'INSERT') transaction_type,
          M.message_size
     FROM TABLE(device_transactions_) D, TABLE(entity_tables_) E, mobile_transaction_message M, mobile_transaction_user U
    WHERE M.app_name        = context_.app_name
      AND M.app_version     = context_.app_version
      AND M.transaction_scn = D.transaction_scn
      AND M.entity          = E.entity
      AND M.transaction_filter_id = U.transaction_filter_id
      AND U.app_name        =  M.app_name
      AND U.app_version     =  M.app_version
      AND U.filter_type_db  =  DB_ALL
      AND U.user_id         =  D.user_id
      AND U.entity          =  M.entity;

Answering your question

1) Can you replicate same in a TEST environment? 
No, I don't know how to recreate it. The last error was found at 29.01.2022 - till today morning it didn't happen again

2) Do you have any custom modifications or layers in the customer environment? 
Yes, but nothing regarding mWO. And nothing which was installed in December or January

3) Also do you have permission Set filters?
Permission filter for users and Groupped Push Filter Map (filter for contract). But the error was also visible for IFSAPP user.

What we can do it enable Grouped Push Trace level to INFO  (This is a app parameter ‘INIT_TRACE_LEVEL’) and take detailed logs. You will need to switch that back to original state after taking logs as this is a production. Also worth check oracle alert logs. I feel like some Oracle low level errors causing data to inconsistent. 

I'll ask customer for Oracle logs. 
How to enable   Grouped Push Trace level to INFO ? Where exactly is that parameter, where are the logs, what are consequences of setting it to INFO (disk space on server required, slowness, etc?)

Did you re try activation again after see this error? Because Groups Push recovers any errors in the next cycle. I think worth try that. Also, You see this error when user try to re initialize their devices. What’s the use case for engineers to re activate / Re initialize devices? 

Customer has reported error after weekend, so I couldn't see it. But customer administrator got that message also when using his iphone and loging as ifsapp. Re initialization was probably done to make sure everything is OK.

Have you reported this to Support yet? 
You mean IFS support? I'd have to recreate that error on REF - I'm unable to recreate it., so I can’t report it now.

Best regards,
Hubert

Hi Kapila,

Thank you for detailed instruction :)  “Save” is enough after changing parameter to INIT_TRACE_LEVEL or should I also restart application server?

Best regards,

Hubert