Skip to main content
M
MA873117416-Pearl
16-Pearl
November 12, 2025
Solved

How to handle button disable + error message when service fails in Mashup?

  • November 12, 2025
  • 1 reply
  • 309 views

Hi everyone,

 

I have a mashup setup with a popup where user can create a new entry.
When the button on this popup is clicked, it first creates a new entry in the database through a ThingWorx service.
Once the service completes successfully, a new popup opens where the user continues the process.

The issue I observed is that some users click the button multiple times, because the service execution takes around 1–2 seconds before the new popup appears — this causes multiple duplicate entries in the database.

 

To fix this, I changed the logic so that the button is disabled immediately after the first click, and it is only re-enabled after the service is complete.
This works well when everything runs fine.

 

However, I now have one new issue:
If the service fails (e.g., timeout, backend issue, or validation error), the button remains disabled forever, since I am only using the “ServiceInvokeCompleted” event.

My question:
 Is there a way in ThingWorx Mashup to detect service failure or exception so that I can:

  1. Re-enable the button if the service fails, and

  2. Show an error message like “An error occurred while creating the entry. Please try again.”

I’m currently using ServiceInvokeCompleted, but it doesn’t distinguish between success and failure.
Should I use ServiceInvokeReturned or any other approach?


How do you usually handle this scenario in ThingWorx Mashups to avoid disabled buttons and duplicate entries?

 

I am already examining why entry creation is not happening instantly. Why this delay is coming there which gives user a chance to manipulate this in a bad way.

Thanks in advance!

Best answer by Rocko

Some random and unsorted thoughts:

-The services called by mashups should never return an exception, if there is an exception it should be handled by the service. 

-There is a widget called status message to display warnings and errors. https://support.ptc.com/help/thingworx/platform/r10.0/en/#page/ThingWorx/Help/Mashup_Builder/Functions/StatusMessages.html

-If you need to return either a result or an error message, create a wrapping DataShape that contains both fields and return that from your service.

-Several ways exists to implement multi-button-click avoidance. You can hide or disable the button or change it's z-axis. all is fair, just keep in mind this must also work with multiple users on the same mashup, and also the service can be called anytime and multiple times by using REST API. Disabling the button happens on the client side only and it should not be your only line of defense.

-Entry creation might take some time or not - you can never make assumptions about the execution time as any component in the process might introduce a delay at any time. You can make these assumptions to see if the application/use case works good in the average case. But you can't make it when considering security, like your last sentence implies. Your perception of "instantly" is still many processing cycles of a thread that can be interrupted.

1 reply

Rocko
Rocko19-TanzaniteAnswer
19-Tanzanite
November 13, 2025

Some random and unsorted thoughts:

-The services called by mashups should never return an exception, if there is an exception it should be handled by the service. 

-There is a widget called status message to display warnings and errors. https://support.ptc.com/help/thingworx/platform/r10.0/en/#page/ThingWorx/Help/Mashup_Builder/Functions/StatusMessages.html

-If you need to return either a result or an error message, create a wrapping DataShape that contains both fields and return that from your service.

-Several ways exists to implement multi-button-click avoidance. You can hide or disable the button or change it's z-axis. all is fair, just keep in mind this must also work with multiple users on the same mashup, and also the service can be called anytime and multiple times by using REST API. Disabling the button happens on the client side only and it should not be your only line of defense.

-Entry creation might take some time or not - you can never make assumptions about the execution time as any component in the process might introduce a delay at any time. You can make these assumptions to see if the application/use case works good in the average case. But you can't make it when considering security, like your last sentence implies. Your perception of "instantly" is still many processing cycles of a thread that can be interrupted.

    Terms & ConditionsCookie settingsAccessibility statement