• Henrique Cabral
  • NEWBIE
  • 0 Points
  • Member since 2018

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 1
    Likes Given
  • 0
    Questions
  • 3
    Replies
Hi Everyone,

does anyone know why the $A.get("e.force:closeQuickAction").fire(); event is not working on aura component after the Winter '20 sandbox update? Or anyone experienced this issue?
Deal all,

I have created an integration with an external service (Google) and am using named credentials in this use-case (with a principal user). There is  strange renewal behavior however, that seems quite reproducible:
- if I try to connect after X time (let's say an hour since this is the token window with Google), the first attempt will give an 401 Unauthorized error. 
- if I retry everything works fine 
- looking at the logs, at the named credential it states: Retry on 401 is true
- however, there is no automatic retry on 401, given that a manual second try does make it work...
- this seems to suggest that SF approach to tokens is to not renewal tokens continuesly, but to get one when needed.
- not an illogical concept given the multitenant nature and that some integrations maybe seldom used. However why does this not work then? I also cannot find any documentation on the renewal process exact nature and/or this setting. 
- I am using a Google Auth. Provider over the general one btw (if that has any influence in the backend at all beside preconfig).

Context: this is especially problematic since as a workaround I am now performing a 'dummy' GET request from the service. However that means it limits my max amount of calls to 50 instead of 100. While in theory (but very seldomly) I could get over 100 anyway and I should probably resort to a batch and/or queable apex approach, however this is so rare that it is not in the 80% range of the current implementation. Under normal circumstances I can however get around 50-70 batched calls, and because of the unexpected overhead of the dummy call this is now suddenly a problem... 

There also seems no possibily to check the token renewal date against the current date fow example? But maybe it is not even saved if my theory about the implementation is correct. The only thing I can think of atm is creating an oAuth flow myself and store it in a custom setting, but that would be quite a dissapointing workaround... There is also no possibilty to place the dml outside of the context of the call it seems to me? 

Any help is appreciated! Thanks in advance! 
Deal all,

I have created an integration with an external service (Google) and am using named credentials in this use-case (with a principal user). There is  strange renewal behavior however, that seems quite reproducible:
- if I try to connect after X time (let's say an hour since this is the token window with Google), the first attempt will give an 401 Unauthorized error. 
- if I retry everything works fine 
- looking at the logs, at the named credential it states: Retry on 401 is true
- however, there is no automatic retry on 401, given that a manual second try does make it work...
- this seems to suggest that SF approach to tokens is to not renewal tokens continuesly, but to get one when needed.
- not an illogical concept given the multitenant nature and that some integrations maybe seldom used. However why does this not work then? I also cannot find any documentation on the renewal process exact nature and/or this setting. 
- I am using a Google Auth. Provider over the general one btw (if that has any influence in the backend at all beside preconfig).

Context: this is especially problematic since as a workaround I am now performing a 'dummy' GET request from the service. However that means it limits my max amount of calls to 50 instead of 100. While in theory (but very seldomly) I could get over 100 anyway and I should probably resort to a batch and/or queable apex approach, however this is so rare that it is not in the 80% range of the current implementation. Under normal circumstances I can however get around 50-70 batched calls, and because of the unexpected overhead of the dummy call this is now suddenly a problem... 

There also seems no possibily to check the token renewal date against the current date fow example? But maybe it is not even saved if my theory about the implementation is correct. The only thing I can think of atm is creating an oAuth flow myself and store it in a custom setting, but that would be quite a dissapointing workaround... There is also no possibilty to place the dml outside of the context of the call it seems to me? 

Any help is appreciated! Thanks in advance!