FSM Metadata is intentionally Read Only because it controls the baseline behavior of the software. Each time the FSM software is updated, the FSM Metadata is overwritten. So even if you were able to edit it, an upgrade to the latest release would overwrite your edit. The purpose of the Custom Metadata is to allow you to override the baseline behavior and not be affected when you upgrade to the latest release.
That was a very big jump in versions. Somewhere between 5.3.3 and 6.15, the data structure changed to using database views instead of tables for some of the stock data. I’m only guessing here, but do you have custom stock screens? If so, create a new custom version using the baseline screen and see if that resolves the issue.
Hi @KristenGastaldo , From Customer Portal, when I Right-Click on IFS Support and select “Open link in new tab,” the new tab opens with “about:blank#blocked” as the address. If I just Click on IFS Support, it takes me to authentication for the Support Portal and I can get in fine. This isn’t blocking me, it just is a minor inconvenience. The Customer Portal doesn’t seem to have much value, so I will typically go directly to the Support Portal anyway.
If you have your metadata set up correctly for the TASK_EXT table as an Extension of TASK, you should never see the TASK_EXT table in the mobile database. Therefore, the mobile client would consider the CUST_FIELD_1 column to be on the Task table. Verify you do NOT have the TASK_EXT table set up in the Sync Rules. Your script should refer to task.cust_field_1.
In general, upgrading FSM 6 from Update 16 to Update 23 should require zero to minimal reconfiguration. However, you may need some configuration to take advantage of new features. Besides following the Upgrade guide, you should also review the Enhancements, Notices, and Corrections sections of the Release Notes for all updates after Update 16. Besides testing all business critical functions, test other features that are mentioned in the release notes. As mentioned in the Upgrade Guide, pay particular attention to the Run Log for the Mobile Upgrade. That will list mobile design/metadata changes that may require some configuration.
Hi @sarahk ,The negative ID for tech_signature_id is expected until the attachment record for the signature has synced with the server. If your solution is configured correctly, the message you are showing should be in the Waiting queue and the attachment message should be in the Ready queue immediately after the client script is executed. I’d recommend Pause Sync right before saving the signature and looking for both messages. If you are not seeing the two messages, then review the configuration to ensure that the metadata relationship is correct between task.tech_signature_id and attachment.attachment_id. I don’t have access to an FSM environment anymore, so hopefully someone else can chime in if this doesn’t resolve the problem.
Hi @ssabo ,Going off memory, the only usage for that MPM can be seen in the Extract records that exist for all Real Time and Batch-Delta sync rules. It is basically a wrapper around the outbound XML message to direct the message to the Mobile Manager to ensure that a message is inserted into mm_message_out for all devices that need to get the message.Regarding MPM parameters in general, you can query the database to see the parameters defined in metadata. Something like: select * from metrix_perform_param where param_name = ‘perform_process_message_to_mobile’. The metadata doesn’t necessarily guarantee that the parameters are functional, but you can get a good idea of what may be possible.
Based on the original question, I believe that Batch-All is the only valid method. If you have a database VIEW in the sync rule, there is no mechanism to trigger any action when data updates. The sync rule must be based on a database TABLE for inserts/updates/deletes to trigger an extract.. There is no baseline business policy that will be executed to send an outbound message if data in the source tables of a view is changed.
Hi @drooij ,Yes, you can certainly create custom database tables and custom metadata to define the custom tables. The question of why you would choose a table or a view would be answered by your purpose for the custom object. It is common to create a view to sync to mobile if you only need to view the data and not update it in the mobile client. A typical use is for service history. In this scenario you should use a Batch-All sync rule.
This indicates something went wrong while upgrading Mobile Designer metadata. The first thing to check is the Run Log with run type of Mobile Upgrade. The details in the run log should give some indication of what when wrong. I would suspect something related to the mm_upgrade_track table not being populated properly before the upgrade attempt. Just a guess based on previous experiences...
This screenshot shows you are upgrading from Update 22 to Update 22, so it will not attempt to upgrade any metadata. The upgrade will only attempt to make changes based on the Initial Designer Build. I recommend opening a case with these details to confirm, but the resolution will likely be to run a db script to update mm_upgrade_track to set a value in designer build to something that matches the version that you previously upgraded from.
Hi @TatKhandM ,A couple of additional thoughts to keep in mind.First, changing a client script is, in effect, creating a new solution for your users. This is not something you should be doing without a change control process, just as if you were upgrading software versions. Short of a production emergency fix, I’d recommend a scheduled process so that all users know they are getting a change and will need to Initialize when the change is available.Second, the other contributors are correct that you can Initialize users from the Mobile Dashboard. However, I think it worth mentioning that you need to be VERY careful doing this. An initialization wipes all data from the device. If users having pending, un-synced updates, they will be lost if you force an initialization from the back end.
Hi @aathi ,The screenshot you are showing is the message that appears after the Device (person_mobile) record has been deleted on the back end. When the mobile device pings the server and finds that the record no longer exists, it will show that message and re-activate to create a new device record in the back end. The device_last_sync_limit app param provides limits on how long the system will build up messages in mm_message_out while a device is inactive (i.e. user is on vacation). With the app param at 10 days, if the user does not sync for 10 days, all mm_message_out records are deleted for that device and a message is created to force an Initialization for that device. If the device still does not attempt sync for 30 days, the person_mobile record will be deleted. This will force re-activation.
Hi @Priyanka Cecilia V ,Besides the mobile design configuration, you also need to set up custom metadata to establish the relationship between the receiving_unit and attachment tables. Best bet is to look at a baseline metadata example such as task_attachment to attachment. You will also need to adjust Sync Rules if you want the attachments to sync back to the device after a change or Initialization.
Hi @drooij ,Yes, you can certainly create a new custom table in the database with the right permissions. I’m going off memory, but I believe you can do it with the built-in SQL Query screen if your role has a function something like ALLOWDBEDIT. If that doesn’t work, then whoever is your DBA can add the table and appropriate indexes. Someone on this community probably knows for sure. I don’t have access to an FSM environment anymore.
I’m guessing you modified the Delivery Method of the sync rules. Since those baseline views have no modified_dttm, the delivery method must be Batch - All. You cannot modify the baseline views because the next time you upgrade your changes will be overwritten.
I’m going off memory, but I believe the person’s calendar has something like a “Count as Capacity” flag for each calendar block. That needs to be checked to show “Expected” time in mobile.
Hi @sarahk ,As @Shneor Cheshin mentioned, the -7 value in the update_task message you are showing is expected. That message should be in the Waiting queue until the separate attachment message that inserts the signature gets uploaded. The response from the server after the attachment is inserted will contain the actual attachment_id for the signature, which will then replace the -7 value in tech_signature_id before mobile uploads the task update.
In general, a status change on the server will not result in a task being deleted in the FSM Mobile database. If you have configured the sync rule to not include tasks with status of OPEN, you will also need to configure your job list screen to not display tasks in OPEN status. You may also need to configure the sync rule’s removal conditions, so the extract will send update messages for task_status of OPEN (just like for status of CO, CL, CA).
@venkatesh ,I believe you are trying to store a time that is independent of time zone. Meaning that it doesn’t matter what time zone a person is in, the field will always show the same value. You should be able to control this by setting the proper Mask Type in the column metadata. I don’t remember exactly, but the value to select is something like DATETIMENOTZ.
Hi @BSiemund ,I am not facing this issue, but have been involved in root cause analysis for similar issues in the past. I suspect that this is related to connectivity and the timing of updates between mobile and the server. It will take a microscopic look at everything that has happened to a specific task during the time frame of the behavior. It’s best if it can be reproduced in a test environment where you can turn logging all the way up without impacting performance for everyone in production.One scenario that could explain this goes something like:9:00 - Mobile user changes task status 9:01 - A dispatcher, business rule, PSO, I/F, etc. makes a change to any other field on the task 9:02 - Mobile device syncs the update task status message to the server, receives the server update (that still has the previous task status), but does not get the response from the server for the status update.After this has occurred, the task record on mobile will have the task status that was receiv
Hi @Shobana ,STOCK_BIN is actually a database View. STOCK_BIN_TABLE is the database Table that holds the data. To the best of my recollection, this was a change done several years back to improve performance and optimize functionality related to stock transactions.
Thanks @Lee Pinchbeck ,I’ve accepted your answer, but it does sound like there may be a design gap with the feature. I will not be using this feature, but I imagine a workaround would be to add hidden fields to a screen for any field that is used in logic for workflow or other reasons. I would recommend thorough testing for anyone who decides to use this enhancement.
Hi Shaik,I’ve been away from FSM for awhile, but from a high-level planning perspective, you should plan on upgrading your FSM solution at a minimum of once per year. Whatever version you are on now will not support future mobile OS versions. It is possible that most or all features in FSM Mobile will work on a new OS, but both Google and Apple often make significant changes that break features they previously supported. The only way IFS is able to support new mobile OS versions is to release a new version of FSM.
Hi @StejonatL ,I’ve been away from FSM Mobile for awhile, so working off memory. The Quick Action bar is a hard-coded feature. All the buttons are only functional on the Overview and Notes screens. The Status button is functional on coded or codeless screens in the Debrief Workflow. The scripting that @SuryaSen mentioned works for hiding or showing the buttons, but there is no way to add quick action buttons to custom screens through configuration. That would require significant code customization.
Already have an account? Login
No account yet? Create an account
Enter your 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.
