Hi

What’s the App10 version? Is this a production environment? Does all users get this issue or only few of them? 

As per the error ,Grouped Push Initialization trying to insert duplicate data in to the mobile out messages table. 

Thanks

Kapila 

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 Hubert,

The procedure Distribute_Transactions___  has two inserts but one for Out message table and other for out message data table.

• Can you replicate same in a TEST environment? 
• Do you have any custom modifications or layers in the customer environment? 
• Also do you have permission Set filters?

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.  

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? 

Have you reported this to Support yet? 

Thanks

Kapila

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

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?)

Go to 

• Solution Manager→ Aurena Native Apps→ Configuration→ Application Parameters and search for your app name, version and parameter INIT_TRACE_LEVEL. Default value is WARNIGN and you can set this to INFO and save.

• If you enable INFO level for INIT then during the Grouped Push Init it gather more data traces in ‘Grouped Push Transaction Traces’. It’s under Logs and Queues sub navigator. 

• So advice is go back to WARNING level again once you have sufficient traces. 

Yes this could be a bug or data inconsistency somewhere. Oracle alert logs might shows the conflicted row keys. If we can find more details about the index violation then can narrow down the issue. If possible make a copy of production and try to user that for replicate the issue. 

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

Only save is enough and this parameter will apply to the Grouped Push Database process in the next cycle (Cycle is normally start in every 10 sec gap).