Hi Hans;Start time of a BG job is depends on how many other pending jobs are queued in the same Batch Queue. Even batch queue configuration is the same, no of BG jobs in the queue might be not the same (may be you can verify that) ? If you do not have any Touch Apps installed on this environment, then there is no load on Queue 4. it fetch your jobs quick. may be you can compare it. ThanksKapila
In App8, you can enable Device Sync Traces (Similar to App9/10). By doing that, you can check SQL traces for client transactions. I think that’s the first place you can start your troubleshooting to see what server methods have been called and also can be seen bind parameters. Also worth check J2EE logs to see any unusual java errors related to mobile activity handlers. Hope this helps.
Hi Please see F1 Technical Documentations for Ignored Error Types. Hope this helps. Apps9: https://wit.ifsworld.com/f1docs/apps9/Foundation1/040_administration/415_touch_apps/020_configuration/020_ignored_error_types/default.htm Apps10: https://docs.ifs.com/techdocs/Foundation1/040_administration/415_touch_apps/020_configuration/020_ignored_error_types/default.htm *Admin note: Replaced wit link with docs link. (April 2020)
I think this is a possible use case in an offline solution. Offline clients could send outdated transactions to the server because field users can perform tasks while the device is offline. When device is online (has a connection to the server), it first send all pending messages in the offline queue to the server and then downloads any pending messaged from the server out queue. This means any operations device do while offline will first reach the server and then the client consumes the out messages in the server. So there is a chance to trigger such failed transactions in the real offline environment. So, those types of failed transaction can be classified as known errors and can be ignored where admin can set up the rule in the IEE to move such FT to ignored queue. Will that solve the issue? Also failed transaction in the queue does not prevent field user to continue their work. Server only queue transactions related to that failed work order.
Hi Isuru;As per the error description, this has been raised from the android FW Touch Apps Access layer. Possibly your server is busy or you have a poor network. If that’s not the case the error does mean more generic and you need to see client logs for any detailed error description. Normally we check TAS is working by login to the admin console. But that does not tell the load on the server. The error is nothing to do with user security.
What you can do is hide this implementation inside a regular VIEW. Then mobile Native Server FW does not need to know about the implementation details at that level. But instead, your application layer hides it from the FW meta data.
This error means the Auth token in the IFS database is invalid compare to what Touch App Server is expecting. Token is used to communicate with TAS in order to send push notifications. If this invalid then you see the error you mentioned in the Mobile Device Logs. When TAS start-up or when configuration has changed in the system, it update the valid token in IFS database by using the activity UplinkServices/RegisterUplinkURL. But sometimes this could fails. One of the common reason is locked user 'IFSMOBILITY'. If that does not solve the issue, then you can recycle TAS connection pool. By doing that, we force TAS to re-register Uplink URL and token in IFS Database. You can check the token’s last register time form the table mobile_push_msg_setting_tab.
[b]Clarification on App Client Version (Apps9/Apps10).[/b] The version you see in IEE under installed app devices is server app version. As Vinu says, this version get automatically updated whenever new cloud application version is published via IFS Touch App Server. You can find the [b]real client version[/b] from the Touch Apps Usage logs. From Touch Apps Admin console, open the Usage log screen. Then you can see exactly what client version is used by end user. However latest IFS Native Framework shows client app version in the Installed App Devices screen. [img]https://uploads-eu-west-1.insided.com/ifs-en/attachment/89071633-911a-4538-a626-1d77b927b653.png[/img]
Initialize device means you wipe out all data in the local database and download fresh data set from the server. Normal scenario is user initialize the device when activate (First time) and then he get data updates automatically via push messages. Server also send batch updates by a schedule. Initialization is a costly operation in server. Specially if the use has large data set. But some cases manual initialization is required when role out major updates (Eg: publish new custom filed to the solution). So unless required initialization is not recommended. Concurrent initialization could also affect the server performance because of server start processing data in parallel. Also this could effect on Touch App Server as well. Scheduled Activation is recommended when customer need to roll out new devices. This will reduce the impact on concurrent initializations activities. With scheduled activation, customer can pre initialize new devices in advance which can be scheduled as batches in
If you are using [b]App10[/b] or [b]App9 (FNDMOB GP 9.7 or above)[/b], then you do not need IMPERSONATE USER privileges to re process failed transactions. You only need the activity '[b]ManageFailedTransactions[/b]’ granted to your permission set. You can grant this activity from the permission set window in IEE application.
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.