Skip to main content
Solved

FIELD-BASED MOBILE EXTRACT RESTRICTIONS

B
Hero (Customer)
Forum|alt.badge.img+6
  • BrianG
  • Hero (Customer)
  • 41 replies

In FSM6 Update 25, a new enhancement has been added to reduce the messages being extracted between FSM Server and Mobile.  What is the logic that determines “If an update message from FSM Server is not relevant to any of the fields used in FSM Mobile designs?”

The name of the new app param indicates that the logic may only be checking if a field exists on a screen in the mobile client.  What about other field changes that are not on a screen but are used in logic to determine behavior?  For example, a client script could select user_def25 from the mobile database, but if that field is not on a screen, an update on the server will not be sent down to mobile.

Best answer by Lee Pinchbeck

Hi @BrianG,

If it still works the same as the customisation that was regularly used prior to it becoming baseline then it checks against the contents of the mm_field_sync_view table. If the changed fields are in there then it will create the update in mm_message_out and if not, it does not.

Quote from the customisation design:

For updates however it will collect the relevant fields from the mobile designs (mm_field). This is done by a custom view “mm_field_sync_view” which will returns a distinct list of fields used.

Not sure if these functional only fields would be in mm_field though, or if there would be an issue adding them if not.

Kind regards,

Lee Pinchbeck

View original
Did this topic help you find an answer to your question?

3 replies

Lee Pinchbeck
Ultimate Hero
Forum|alt.badge.img+24
  • Lee Pinchbeck
  • Ultimate Hero
  • 1219 replies
  • Answer
  • July 31, 2023

Hi @BrianG,

If it still works the same as the customisation that was regularly used prior to it becoming baseline then it checks against the contents of the mm_field_sync_view table. If the changed fields are in there then it will create the update in mm_message_out and if not, it does not.

Quote from the customisation design:

For updates however it will collect the relevant fields from the mobile designs (mm_field). This is done by a custom view “mm_field_sync_view” which will returns a distinct list of fields used.

Not sure if these functional only fields would be in mm_field though, or if there would be an issue adding them if not.

Kind regards,

Lee Pinchbeck

Currently reading: The Way of Kings - Brandon Sanderson
J
Do Gooder (Customer)
Forum|alt.badge.img+6
  • jevin.fernando
  • Do Gooder (Customer)
  • 26 replies
  • August 2, 2023

@BrianG I had this question too. Thanks for creating a post

Since mm_fields cant be actually used to determine the extract logic, as we use the non mm_fields in client scripts.

So since we mostly define the fields that we require in the sync rules, cant we use them to have this logic? May be when a sync rule is updated, we store the defined fields in a table, and utilize them also in the SQL view “mm_field_sync_view” ?

A suggestion @Lee Pinchbeck 

B
Hero (Customer)
Forum|alt.badge.img+6
  • BrianG
  • Author
  • Hero (Customer)
  • 41 replies
  • August 3, 2023

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.

 

H
1 person likes this
  • H
    Hasara Gunasiri

Reply


Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings