Skip to main content

We’re experiencing some difficulties with developing new functionality on mWorkOrder Windows revision.

The new entity was added to resource library, which then was successfully deployed to TAS.

We see the new entity in IFS IEE and the new entity’ table in local database on mobile as well.

All the data was received in local database for new entity, too.

Further, our new entity contains the Temporary Client Key.

In our case, mobile framework successfully generated this key.

But when we try to send the new data record for mentioned entity from mobile client to server we have the problem with “real” server-side key replacement on sync.

We’ve got the failed transaction with error ORA-20124: Error.NULLVALUE.

Maybe we’re doing something wrong?

Or maybe we don’t complete some action in development process (for example, on server side)?

First thing you need to check is the cloud resource. You should have 2 filed properties (Key = true, TemporaryClientKey = true)  for the key attribute. Also you can check the entity meta data. You should have server generated key view comment (i.e. KM--L). 


Thanks for quick answer! As I see, yes - our key field has mentioned properties (Key = true, TemporaryClientKey = true) for the key attribute in cloud resource. We, also checked the server generated key view comment - it was KMI-L, but we changed it to KM--L. Still the same error ORA-20124: Error.NULLVALUE. Maybe there are some more things to check? 


Can you please post Incoming data in the Failed Transaction?  How many application versions installed in your backend? Normally you have one active. This is just to see if this is related to app versions. Also you can enable sync traces for your installed app device and do additional checks based on the stack trace when this error happens. 


Thanks for answer! We’ve attached Failed Transaction details and the sync trace as well. Yes, we have a lot apps/devices per user, but only one is active at the moment. We don’t know now where to look at. Seems to be, that all have to work, but the result is negative.


Do you get any result from below query?

SELECT a1.*
FROM IFSAPP.MOBILE_CLIENT_KEY_MAP a1
WHERE a1.DEVICE_ID = '383'
AND a1.USER_ID = 'DANMI'
AND a1.APP_NAME = 'mWorkOrder'
AND a1.ENTITY = 'ProductionLogEvent'

Still your entity view meta shows as KMI. May be you need to clear the Dictionary Cache after update entity and re deploy app meta again. 


We’ve done the Dictionary Cache refresh and after that redeploy the resource library again. The entity has the same properties as earlier. The result from your provided query is null.


What’s the value in the column Mobile_Entity_Attr_Tab.Temporary_Client_Key for this attribute?


The value for the column Temporary_Client_Key in the mentioned table is TRUE. Please, see the attached screenshot.


You have changed the entity view comment to KM-- and did you also set the server key in PL logic before saving the record (Either in Check Insert or Insert)? 


Sorry, what exactly do you mean? I think that the entity is generated through the resource library deployment, is it so? So, I’m not changing the entity view comment, only the base view for Logical Unit. Where exactly I have to set the server key in PL logic? In what package?


Normally we override Check_Insert___  of the relevant LU and set the key value when the key is server generated. I think that’s the issue here. if we don’t do it this mobile transaction fails with that error.  But I also think this is not a TRUE server gen key because it had KMI. That means it’s insert allowed key where client generates and send to server. So you need to decides here. I think best is align the functionality to behave same where LU key is server generated means LU check_Insert set the key. 


Yes, this worked for us. We’ve got the new record from mobile. Thanks for your assistance! It was very helpful!

But now we have the problem with client key replacement with the server key on mobile. Nothing happens with synchronization, the temporary client key still there. Only when we made initialization we’ve got the client key changed.


Yes that’s by design. We do not replace temporally client keys today. One of the reason we didn’t do that because of your app is designed to run in the offline mode. So what end-user sees in the key field in the first place is the value he knows. If we switch the value in his device in the middle when he get signal  could confuse the end-user. 

What you can do from the app layer is show the server key value in an another filed. You can either send it via the server or can fetch from the local  table called ‘Client_Key_Map’. Hope this will help you to resolve your next issue :relaxed: