• Community
  • Groups
  • Alliance
  • Changes made by Process Flow are not downloading to Mobile like when the item is changed in back-office
Solved

Changes made by Process Flow are not downloading to Mobile like when the item is changed in back-office

  • 27 October 2023
  • 12 replies
  • 176 views
K
Rank
Userlevel 2
Badge +6

We created a process flow which updates installed items. This is working well but we noticed that the change is only visible in Mobile after the user reinitializes . If the installed item is changed in Backoffice, the change is visible in Mobile almost immediately. The item.last_change_date field is is updating automatically in both cases. Is there a trick to getting the process flow change to download to Mobile?

icon

Best answer by Andrew D'Antonio 26 April 2024, 15:29

View original

12 replies

Reid Gilbert
Rank
Userlevel 7
Badge +15

Hi Katherine,
What fields are you updating on the installed item record?
Is the process flow updating these fields at the database directly (via SQL)?  Or is it doing it through an API talking to the installed item module in Alliance?  If it’s being done through an API can you give us an example to look at?
Thanks,
Reid

K
Rank
Userlevel 2
Badge +6

Hi Reid,

Thank you for the quick response. 

The process flows are updating the installed item via an API call.  We have multiple process flows which are updating custom fields and one that updates the Item Notes field. 

Here is one Process Flow Action example:

<root xmlns:dt="urn:schemas-microsoft-com:datatypes">
    <session email="" alias="">
        <state bc_name="item_installed" use_cache_refresh="False" is_retry_on_optimistic_error="true" max_retry_on_optimistic_error="50">
            <action name="data">
                <main>
                    <row number="1">
                        <item_id in_var="" out_var="">{item_id}</item_id>
                        <cst_phase in_var="" out_var="">{new_item_phase}</cst_phase>
                    </row>
                </main>
            </action>
        </state>
    </session>
</root>
 

Thanks,
Katherine

Reid Gilbert
Rank
Userlevel 7
Badge +15

Can you run a quick test where that API populates the tagno field (add a line right above your cst_phase entry and just put a random value in the tagno field, just make note of the original value so you can set it back to the previous value afterwards), I just want to see if triggering a change to a standard field will get the update pushed out to mobile).
Thanks,
Reid

K
Rank
Userlevel 2
Badge +6

Hi Reid,
 

Thank you for the suggestion. We ran multiple tests and here is what we discovered:

1. Updated in Back Office - Installed Item on a call

  • Standard field changes are visible immediately.
  • Custom field changes not visible immediately unless work list is refreshed.
  • If a standard field is also updated in back office, all changes will be visible immediately.

2.  Updated in Back Office - Installed Item not on a call

  • Standard field changes are visible immediately.
  • Custom field updates not visible even after work list is refreshed. Need to reinitialize to see the change.
  • If a standard field is also updated in back office, all changes will be visible immediately.

3. Updated by Process flow - Installed Item on a call

  • Refresh shows the changes for both standard and custom fields.

4. Updated by Process flow - Installed Item not on a call

  • Refresh will not show the changes for standard or custom field without reinitializing.
S
Rank
Userlevel 2
Badge +5

Hi Reid,

Katherine and I are working to finalize some changes and we are hoping you could provide any additional information regarding our latest testing notes above.

Thanks,

-Nick

Reid Gilbert
Rank
Userlevel 7
Badge +15

Hi Nick,
I don’t know the exact details of the criteria that is used to determine whether a change should be dispatched out or not in these cases, hopefully one of the developers can comment on the logic that is being used here and maybe that will shed some light on it...
Thanks,
Reid

S
Rank
Userlevel 2
Badge +5

Hi @Reid Gilbert, hope all is well.  Can you please ask one of the developers if they can please comment on this topic?

Thanks,
-Nick

Reid Gilbert
Rank
Userlevel 7
Badge +15

Now adding @IgorKevesh...

S
Rank
Userlevel 2
Badge +5

Hi @Reid Gilbert and @IgorKevesh 

We are still trying to figure this issue out on why the changes made by a process flow are not being registered in the same manner as when manually updating a standard field on the installed item.

In our testing we found that there is a call to a stored procedure that inserts records into the mobile_messages table which seems to be the key to pushing the changes down to Mobile device.  The process flow does not insert into this table so the change does not seem to push out to Mobile without performing a refresh/reinitialization.  

Is there a way to have the process flow also insert a record into the mobile_messages table?

Thanks,
-Nick

Reid Gilbert
Rank
Userlevel 7
Badge +15

Hi Nick,
I would suggest logging a ticket for it at this time, this will probably require technical assistance from our Services team.
Thanks,
Reid

A
Rank
Userlevel 7
Badge +10

Installed Item dispatches only occur when items are added, deleted, or a subset of standard fields are changed.  To work around this limitation, we added the following section to the API so that when the item is updated via Process Flow, a forced dispatch occurs:

<root xmlns:dt="urn:schemas-microsoft-com:datatypes">

  <session email="" alias="">

    <state bc_name="item_installed" use_cache_refresh="False" is_retry_on_optimistic_error="true" max_retry_on_optimistic_error="50">

      <action name="data">

        <main>

          <row number="1">

            <item_id in_var="" out_var="">{item_id}</item_id>

            <cst_phase in_var="" out_var="">{new_item_phase}</cst_phase>

            <cc_mobile_item_event>AddItem</cc_mobile_item_event>

          </row>

        </main>

      </action>

    </state>

  </session>

</root>

K
Rank
Userlevel 2
Badge +6

Thank you Andrew. The solution you proposed worked perfectly for our issue.

Reply


Terms & ConditionsCookie settings