The apps shows below screen when the connection to server is unsuccessful, but our customer doesn't wan the user to be able to view the "Details" of the error which I had no idea how to remove it. Can we override the default behaviour and show a custom screen instead?
Thanks in advance.
You can use WL.Client.Connect API to connect to Worklight server, and use it's onSuccess and onFailure callback functions to show the users whatever you want. More information can be found here: http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.dev.doc/devref/t_ConnectingToWorklightServer.html?resultof=%22%63%6f%6e%6e%65%63%74%22%20
If you had specified the
ConnectOnStartUp=true
in initOption js file then on starting up itself it will try to connect with the server , In that case use there will a for connection failure,it will be commented first in init Option.You have to uncomment it in initOption js file and give something to do when the connection has failed in that function . So the error will be customized
Related
I want to deploy my app to the shiny cloud server using Rstudio 3.2.5. When I do I get this error:
Error: HTTP 400 POST https://api.shinyapps.io/v1/applications/ Validation Error
How do I resolve this?
install.packages('rsconnect')
library(rsconnect)
rsconnect::setAccountInfo(name='name', token='token'", secret="secret")
rsconnect::deployApp('C:/Users/path/of/R/app')
or
shinyapps::deployApp("C:\\Users\\path\\of\\R\\app")
This one was bugging me for a while today. Turns out the app name has criteria (these aren't mentioned if you just deploy via the button or command)...
App name needs to be minimum 4 characters with no spaces. Try a new name for the app and see if that works.
I was using more than 4 letter word for my app. But the issue was more due to firewall of my company I guess. I disconnected from VPN and tried deploying using public wireless and it worked.
I currently registered my Quecklink GV500 to cumulocity and I'm able to receive some events and measurements.
But when I try to send command to my Quecklink GV500 registered in Cumulocity but I always hava a FAILED response. For example, I tried to send this command (which is fully supported by the GV500) from SHELL tab: AT+GTTMA=gv500,+,1,0,0,,,,,,FFFF$
And as result I got:
Failure reason: Command currently not supported
I also tried to get the agent logs by using "Log file request" in the "Log" tab of my Device and as result I got:
Failure reason: Cannot build command. Search parameters only allow the
following characters [a-zA-Z0-9_]
Is it normal?
When I look the general information in "Info" tab I have:
Send connection: online
Push connection: inactive
Is it normal that Push connection is marked as inactive?
The tracker-agent in it current state does not use a push connection for receiving operations but does a polling of the operations. Therefore the push connection is always shown as inactive.
If you receive "Failure reason: Command currently not supported" it is an error from the agent not the device. The agent seems not to support shell operations for Queclink.
As for the error on the log file request it seems that there was an unsupported character in the search parameter. Maybe you can share what you entered for the parameters in the UI
Thanks for your answer. For the log file request I let blank value in the search input field. If I try to enter "gl200", I get the following error: Command currently not supported.
So to resume can you confirm that Quecklink devices can't be managed from Cumulocity for the moment? It's supported for which device?
I am trying show end users maintainence window such as "we are down please try later" and disable the application but my problem is what if my worklight server itself is down and not reachable and i cannot use the feature provided by worklight console,
Is there a way i make my app talk to a different server which returns back the below json data when a app is disabled , can i simulate this behaviour is this possible.
json recieved on access disabled in worklight :-
/*-secure-
{"WL-Authentication-Failure":{"wl_remoteDisableRealm":{"message”:”We are down, Please try again soon","downloadLink":null,"messageType":"BLOCK"}}}*/
I have some conceptual problems with this question.
Typically a production environment (simplified) would not consist of a single server serving your end-users... meaning, there would be a cluster of nodes, each node being a Worklight Server, and this cluster would be behind a load balancer that would direct the incoming requests. And so in a situation where a node is down for maintenance like in your scenario there would still be more servers able to serve - there would be no down time.
And thus at this point your suggestion to simulate a Remote Disable by sending it from another(?) Worklight Server seems not so much the correct path to take (it may even be simply wrong). Have you had this second Worklight Server, why wouldn't it just serve the apps business like usual? See again my first paragraph about clustering.
Now lets assume there is still a downtime, that affects all servers. The application's client logic should be able to handle failed connections to the Worklight Server. In such a case you should handle this in the WL.Client.connect()'s onFailure callback function to display a WL.SimpleDialog that looks just like a Remote Disable's dialog... or perhaps via the initOption.js's onConnectionFailure callback.
Bottom line: you cannot simulate the JSON that is sent back for the wl_RemoteDisable realm; it is part of a larger security mechanism.
Additionally though, perhaps a way to better handle maintenance mode on your server is to have the HTTP server return a specific HTTP status code, check for this code and display a proper message based on the returned HTTP status code.
To check for this code in a simple example:
Note: the getStatus method is available starting MobileFirst Platform Foundation 7.0 (formerly "Worklight").
function wlCommonInit(){
WL.Client.connect({onSuccess:success, onFailure:failure});
}
function success(response) {
// ...
}
function failure(response) {
if (response.getStatus() == "503") {
// site is down for maintenance - display a proper message.
} else if ...
}
using Worklight server v6.1 i'm trying to develop a simple app that connects to the production server at startup. To get this i do:
in initOptions.js file i set connectOnStartup to true
in wlCommonInit method of <my-app>.js file i call :
WL.Client.connect({
onSuccess: connected,
onFailure: failure
});
where connected and failure are two callback to two simple functions that load some data in a listview. When i trie it on a production or development environment i get a spot over my app's layout stating it's loading as you can see in the pic below(even if the application loaded data correctly):
i notice that after installing and running it on an iOS or Android device i don't have this strange behaviour, but on Windows8 devices i do have.
i set to false connectOnStartup and left only the call to WL.Client.connect.
Now the app doesn't get blocked anymore(i suppose becouse WL.Client.connect runs asynchronously while WL.Client.init does not but it's only my opinion).
i can't connect to the server yet, this is strange becouse(you can see in the pic) there is a listview filled with data returned by a sql adapter,
so it looks like the app can connect to the server for calling adapters but not for updates
You have already set connectOnStartup:true in initOption.js, this means that the app will try to connect to the Worklight Server on startup - basically it calls to connect, so why do you call WL.Client.connect in wlCommonInit() as well?
As for the onSuccess and onFailure, I think that in this what you may want is the following:
See the options for WL.Client.init.
There is an initOption that you can uncomment in initOptions.js:
onConnectionFailure
A failure-handling function invoked when connection to the Worklight
Server, performed on initialization by default, or if the
connectOnStartup flag is true, fails.
The "success" by default is wlCommonInit(), but you want something else then in initOptions.js you can also add onSuccess: something.
BTW, where did you see what you've done as a "best practice" by Worklight?
We are using an extjs form to upload our files to fileserver ( we have an FileUploadHandler.ashx to handle the file on the bakcend side )
My question is, can extjs handle / throw an exception if accidentally during the upload process the user was disconnected from the network / internet
Thanks in advance.
You'd have to handle that on the server side. I don't believe ExtJS can handle that, it can only handle responses from the server. So, if your server throws a 500 or another error code that indicates that the request was unsuccessful, you can handle that.