MobileFirst Direct update customization using adapter - ibm-mobilefirst

Question

I am trying to customize direct update by getting all the messages from an adapter.
I am not getting adapter success callback if direct update is triggered.
I want to show a dialog giving option to the user to cancel direct update.
Below is the code I am trying with:
wl_directUpdateChallengeHandler.handleDirectUpdate = function (directUpdateData,directUpdateContext){
console.log("Test for directUpdate");
var invocationData = {
adapter : 'DirectUpdateCustomizationAdapter',
procedure : 'getConfig',
parameters : ["android","1.9.0"]
};
var result = WL.Client.invokeProcedure(invocationData,{timeout: 30000,
onSuccess : function(success){
console.log("Adapter call success" + JSON.stringify(success));
},
onFailure : function(failure){alert(3);console.log("Adapter call fail" + JSON.stringify(failure));},
});
};
I am using the below security test:
<customSecurityTest name="customTests">
<test realm="wl_antiXSRFRealm" step="1"/>
<test realm="wl_authenticityRealm" step="1"/>
<test realm="wl_remoteDisableRealm" step="1"/>
<test realm="wl_directUpdateRealm" mode="perSession" step="1"/>
<test realm="wl_anonymousUserRealm" isInternalUserID="true" step="1"/>
<test realm="wl_deviceNoProvisioningRealm" isInternalDeviceID="true" step="2"/>
</customSecurityTest>
If direct update is not triggered and adapter call is outside challenge handler then adapter call is successful.
Please guide.

Answer 1

What does direct update has to do with adapters?
You cannot invoke or handle it in adapters; it must be handled on the client-side, as it is the client-side SDK that handles direct update, and not adapters, which reside on the server-side.

Answer 2

for such flow to work , the method DirectUpdateCustomizationAdapter#getConfig must be stripped from any security and use unprotected access.
meaning: in the DirectUpdateCustomizationAdapter adapter's xml file
the method getConfig should have an additional property :
<procedure name="getConfig" securityTest="wl_unprotected" />
since getConfig returns non-confidential data I believe its ok to un-secure it.
such change in the adapter code requires to re-deploy the adapter file to the Worklight server.
Nevertheless, retrieving data from remote server during direct update handler is not recommended. As Idan stated here, the best approach to customize the title,body and other text elements is actually having those strings in some property file on the device (network hop does cost time).
Updating such property file with new text can be done via the direct update mechanism itself (just like updating any other web resource).