Skip to main content
Solved

Universal loading sequence on networks with lag.

Freddy
Forum|alt.badge.img+16
  • Freddy
  • Thinkwise Local Partner Brasil
  • 528 replies

Hi,

Response times (ping) are sometimes quite slow and we are noticing with the Universal GUI that it creates some odd/unwanted behaviour. Especially when it comes to defaults, layouts and contexts..  they appear to get loaded at last. Which means that tasks, tabs and als fields that get disabled via procedures stay open between loading entity and the loading and application of the def/lay/ctx procedures. 

A similar thing happens after executing a task. During execution the task is greyed out..  but short after it gets enabled again. Due to the sometimes high latency the refresh is not instant. The user gets the option to click the task again. 

What are the options here to deal with this? Can we somehow group entity loading including procedures that influence it's behaviour?  

Best answer by Erik Brink

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.

View original
LEF — Lift. Empower. Fulfill. [lef.digital]
Did this topic help you find an answer to your question?
This topic has been closed for comments

5 replies

M
Rookie

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 

Freddy
Forum|alt.badge.img+16
  • Freddy
  • Author
  • Thinkwise Local Partner Brasil
  • 528 replies
  • May 23, 2023
Mark Kroes wrote:

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:

 

 

LEF — Lift. Empower. Fulfill. [lef.digital]
Erik Brink
Moderator
Forum|alt.badge.img+5
  • Erik Brink
  • Moderator
  • 497 replies
  • Answer
  • May 25, 2023

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.

Freddy
1 person likes this
  • Freddy
    Freddy
Freddy
Forum|alt.badge.img+16
  • Freddy
  • Author
  • Thinkwise Local Partner Brasil
  • 528 replies
  • May 25, 2023
Erik Brink wrote:

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?

 

LEF — Lift. Empower. Fulfill. [lef.digital]
Erik Brink
Moderator
Forum|alt.badge.img+5
  • Erik Brink
  • Moderator
  • 497 replies
  • May 26, 2023

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.

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings