Ok, that's what I thought. But in terms of a robust design, you can't assume the service execution will be always three seconds. There might be changes to the system, or an unusual load on the system which might cause this to be longer.
You could try to solve this on client side (see below), but remember there could be many users using the same mashup (which on client side you have no control over), also someone might call the service directly via REST API and won't use the mashups at all. So it might be better so solve that on server side, e.g. by setting a session variable or a thing property on service execution and when the service is called a second time while it is still running, this can be detected and execution simply be skipped. That way the users could click the button, but nothing would happen.
In case you want to solve client-side (i.e. in mashup code), the event you want to wait for is not when 3 seconds have passed, but when the service actually returns. So for this use case, you would rather bind to the "ServiceInvokeCompleted" event on the data tab of the service called by clicking the button than to have a fixed 3 second auto-reload.
Now you have an event, but then, the button takes a boolean input - you will have to use expression to convert events to a boolean input you can then bind to the button. What you can't do is to simply write two expressions, one to disable and one to enable the button, since you can only bind the "Disabled" property of the button once, plus you can't get the current state. A way of solving this would be to add a hidden (non-visible) checkbox which has a "State" property which can be an input to an expression. You wire the checkbox state to the buttons Disabled property and the expression would use the State and return the negated value.
