Hi Freddy,
Probably we can make the GUI respond better to this, but that won't improve performance. The question is what makes those calls slow. If the subject itself is already slow, that also affects the logic calls and vice versa. Perhaps that can be optimized?
Can you perform an analysis on which part of that subject exactly causes the delay?
https://docs.thinkwisesoftware.com/docs/deployment/universal_troubleshooting
Hi Freddy,
Probably we can make the GUI respond better to this, but that won't improve performance. The question is what makes those calls slow. If the subject itself is already slow, that also affects the logic calls and vice versa. Perhaps that can be optimized?
Can you perform an analysis on which part of that subject exactly causes the delay?
https://docs.thinkwisesoftware.com/docs/deployment/universal_troubleshooting
Hi @Mark Kroes
We are constantly looking for performance improvements, however the infrastructure here is very diverse, so depending on our location we have to accept slower and instable connections.
Therefore this post, I want to know my options to minimize the odd and unwanted behaviours. I really hope there can also be some attention for this from the development team of the Universal where it comes to smart loading such as combined loading of subject with coupled business logic.
And also more visual indications in wait times:
The first preparations are already made to return the results of the application logic in the same call as the stage/patch/commit (default and layout stored procedure while editing and filling in task/report parameters). So, there are plans to optimize this at our side.
@Arie V reported a ticket lately about task visibility which is lacking behind on a slow netwerk (context stored procedure).
We are not sure it you are facing other cases, we are missing here.
Due to the character of the interface we don't want to block or hide elements to keep the interface calm, but I agree we need some smooth indication about running logic in behind.
I have to say, this is not on top of our priority list atm.
The first preparations are already made to return the results of the application logic in the same call as the stage/patch/commit (default and layout stored procedure while editing and filling in task/report parameters). So, there are plans to optimize this at our side.
@Arie V reported a ticket lately about task visibility which is lacking behind on a slow netwerk (context stored procedure).
We are not sure it you are facing other cases, we are missing here.
Hi Erik.
Good to hear there are already advancements in this area. For me the most important area is the coupling of related loading application logic with the subjects it influences. To not have availability of something that should be blocked through logic.
Any insights in the development timings?
It is purely lacking visually. Indicium won't accept any action executed which is not allowed by the logic.
As I mentioned is doesn't have our priority at the moment, so we can not say anything about the planning yet.
