Get progress information from ObjectTypeOperations.RefreshExternalObjectType

We have a tracker item that relates to this: 171137.  Work on this has already been done and it should come out in the December release.  This specifically deals with the fact that quick refreshes can cancel a full refresh.  I wonder what type you're using here.

I would also query why you are using this approach rather than simply altering the default refresh timing behaviour using the Advanced Vault Settings.  Can you give me some more information on that?

Thank you for your answer.
We have faced the problem of quick refreshes canceling full refreshes. Looking forward to the December release.

We want to do periodic full refreshes, not caused by user action. That's what our VAF functionality is for. TO our understanding, the refresh timeouts that are configurable in the Advanced Vault Settings only get triggered, when users interact with the data, right?

Thank you for your answer.
We have faced the problem of quick refreshes canceling full refreshes. Looking forward to the December release.

We want to do periodic full refreshes, not caused by user action. That's what our VAF functionality is for. TO our understanding, the refresh timeouts that are configurable in the Advanced Vault Settings only get triggered, when users interact with the data, right?

There's a set of options, but you can also change the default refresh behaviour: Default Refresh Logic and Configuration Options for External Value Lists and Object Types.  Yes, I believe it does require that the user is interacting with the vault for the refresh to happen.  Just double-check that documentation and make sure that you can't make it do what you want out of the box.

As a general point I would personally argue that you make a decision: either you let the default implementation handle the refresh logic via the configuration options above, or you take the default implementation out of the equation and you implement everything yourself via a VAF (e.g. the VAF actually connects to the other system, processes the data set, creates/updates/removes objects, etc.).  The latter option is obviously a lot more work so shouldn't be undertaken lightly, but I have seen situations (e.g. with millions of objects) where it's had a very positive impact.  The issue you have here is because the two are mixed and that's what is causing the behaviour you're experiencing, although I acknowledge that the server could be more clever (which is hopefully what the tracker item above will help with).

That said: if you are just issuing a quick refresh then my understanding is that the December release should help here and the default implementation (which you then invoke via the API) may then suffice.