Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
vegard_bakke
Partner - Creator III
Partner - Creator III

How to handle qlikk.app.field() being aborted?

I have a mashup, where occasionally the GetField websocket frame gets aborted.

My code is:

var field = self.app.field(fieldName);

field.selectValues(values, isMultiselect, true).then(function (result) {  ...; }).catch(function (error) { ...; });
I've noticed that when everything works, the 'field' contains a member also called 'field'.
But when it fails, this subsequent 'field' member is missing. (The rest on the members are still there.)
 
The 'catch(error)' is never executed.
 
 
What is the correct way retrieve the 'field' object, and potential rerun the request if it is aborted for some reason?
 
 
Cheers,
Vegard 🙂
Labels (5)
5 Replies
vegard_bakke
Partner - Creator III
Partner - Creator III
Author

Using Qlik Sense November 2018, by the way.
Aiham_Azmeh
Employee
Employee

Hi @vegard_bakke ,

We did an improvement in the coming releases, fixing that if the GetField request gets aborted, it will be automatically retried.

Your snippet code looks OK, but if there is any other "data interaction" anywhere else on your code (clear, select, patch etc...) you do have to make your calls in sequence. ex:

app.clearAll().then(()=>{
  app.field('my_field').selectValues([....])
});
// if done synchronously ex:
app.clearAll();
app.field('my_field');
/* there will be a race condition: if the app.field('my_field') resolves before the data model
* change (app.clearAll) -- all OK; but if clearAll resolves before app.field then you will
* end up in a Request Aborted that will not be retried
*/

I hope this helps

 

 

vegard_bakke
Partner - Creator III
Partner - Creator III
Author

Good point. But no, it doesn't look like it.   I have now commented out the clearAll() method, just to be certain.

What do you mean by "...it will be automatically retried".  What effect will that have in this case?

 

There are two 'DestroySessionObject' frames just before the error occurs. 

Below are two examples of the same action. The first results in an error, the second works ok.

 

Sample 1 - Fails

On the mouse click as 16:42:00, two DestroySessionObjects are sent immediately before GetField.

These return successfully, while the GetField is aborted.

(Notice the 20 second pause before the frame in question.)

GetField - Requests - Fail.png

The response frames:

GetField - Response - Fail.png

 

 

Sample 2 - Works

On the mouse click as 16:45:00, the same two DestroySessionObjects are sent immediately before GetField.

(Even got the same id, 42 : )

GetField - Requests - Succsess.png

The response frames:

GetField - Response - Succsess.png

 

 

Differences

The only difference in these two scenarios is that I start by pressing Ctrl-F5 in Chrome in the first sample that fails.
But in the second sample, I only press F5 to refresh the page.

 

Somehow the Ctrl-F5 leads to something being cleared, resulting that the GetField gets aborted on this changing between these two specific mashup pages.

 

Improvement of GetField

What sort of improvement did you do?  If GetField gets aborted, would the server / Qlik api re-run the request? Or would I need to check something, and rerun the request in the mashup code?

 

Do you happen to know what "the coming releases" might be? Will it be included in patches to some previous releases, or only in the next main release?

 

 

 

Thank you so much for a really quick reply! 

I really really appreciate when the Qlik employees that are actually fixing Sense is replying to the community forum.  Smiley Very Happy It saves a lot of time for both the end users, other users, Qlik Support, and the whole red tape process.  I really hope you guys will be allowed to continue providing this kind of support! 🙂


 

Cheers,

Vegard

 

Aiham_Azmeh
Employee
Employee

Hi again,


So clearAll is just one example method that can trigger data model changes and potentially "abort" on-going requests (in this case GetField). As in the clearAll method case, you can sequence the Engine calls:

Promise.all([destroyFn, destroyFn]).then(()=>{
  app.field('my_field').selectValues([...])
});
// can be more readable if you can use async await

The implemented improvement will do retry request for any Get method that got aborted by a data model change - this means that it will not matter anymore if you have a clearAll or destroySessionObject, the GetField method will automatically retry the request until you get a field (or a valid response from the Engine). Unfortunately, this will not be patched on any older release, there is a workaround for it.

BTW, thank you for reporting in such details your issue - community.qlik.com is actually our main source of API improvements.

 

vegard_bakke
Partner - Creator III
Partner - Creator III
Author

I don't see why destroying a session object should abort a get field in one case, and not in an almost identical situation. But that's okay. As you say, abortions may happen for a number of reasons, and we need to handle them. And if the Qlik API will do that from now on, I'm happy. 🙂


If the client side of the GetField API will retry whenever the requests gets aborted, I won't need to do anything, which makes me even more happy. 😄

Do you know if this fix was included in the April 2019 release, or if it was targeted for June 2019 release?

Cheers,
Vegard