Skip to main content

Hi,

We’re currently working a project to update from FSM5.7 to FSM6u23.

As part of testing we’ve seen that since FSM6u6 that Broadcast Plans no longer update the tasks directly with the allocation data, instead this has gone to a new table called dse_allocation. The task is then directly updated as part of a commit process.

 

Just wondering how other companies have either embraced this, or made changes to get the task directly updated based on the plan. 

 

We have a decade plus of Processes, Business Rules and Scheduled Tasks that uses the Task data as and therefore we’d really like to keep it that way for this release.

 

Any information from other users would be greatly appreciated.

 

Regards

Ady

Hi,

 

Anyone in the community had to deal with this major change in the PSO to FSM Broadcast integration? If so did you change the way you work, or did you get a customisation to revert the process back to how it was perfectly fine before?

 

Cheers

Hi @AdrianEgley,

The changes were brought in as the direct update was causing slow performance issues and errors in FSM6.

The change has been dealt with either by putting in place some metadata or business rule to link the required tasks fields to the dse_allocation data, to change process rather than the app or to instead use the PSO dashboard rather than the FSM client for users that required the allocation and routing information.

It all comes down to what precisely is being tracked coming back from PSO and what it is being used for.

Please bear in mind that if the fields are linked back up then you run the risk of re-introducing the performance issues and row errors seen before the change.

Kind regards,

Lee Pinchbeck

@Lee Pinchbeck 

Thanks for the response. I’m currently investigating different ways with Business Rules, but that in itself is causing some other issues (for example updating tasks will just re-send data to PSO).

I also understand the issue around the concurrency errors as we see this on a daily basis, and with the task table being a key data table it’s going to be receiving updates from various sources.

You reference “if the fields are linked back up” - does that mean in your experience you have seen customer revert back to the Broadcast directly updating the task?

I’d love to get our user base to switch away from FSM SB to the PSO Workbench, but operationally it would be really difficult to achieve.

Ady

Hi @AdrianEgley,

Not seen anyone revert to direct from the broadcast to the task table, not sure that’s even possible. I was referring to creating links between the dse_allocation table and the task table to control the update to that table on your terms rather than it only coming through on commit.

The other option is to get the process to trigger off the dse_allocation table instead of the task table. 

It would depend on the specifics of each process, it may be that the best answer for you is some combination of the options. It would likely be too in depth to go to that level in the forums though.

Kind regards,

Lee Pinchbeck

Reply


Terms & ConditionsCookie settings