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.
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.
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.
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.
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.
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.
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.
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.