The server "srvdev.x.x" has the OE webserver running with the mobile rest application, but is not accessible from outside the intranet.
The server "outside.x.x" is accessible from outside, and can also access "srvdev.x.x"
I redirect "outside.x.x:8970" to "srvdev.x.x:8970".
When I go to "http://outside.x.x:8970/MobileService , I get the expected page with "rest". So the redirection is working.
But when I go further to "http://outside.x.x:8970/MobileService/rest , I get the expected page with:
Available SOAP services:
| Endpoint address: http://srvdev.x.x:8980/MobileService/rest/MobileService WADL : http://srvdev.x.x:8980/MobileService/rest/MobileService?_wadl |
The WADL is the XML-file which lists all available rest-methods available to the outside world, and is needed to make anything working when I set the serviceURI and catalogURI in the cloud mobile appbuilder to "outside.x.x...". Clearly this is not working because this address to the WADL is pointing to the intranet address.
1) Where can I change this address of the WADL?
2) The WADL itself contains XML with a tag <resources base="http://srvdev.x.x:8980/MobileService/rest/MobileService"> This will have to be changed also of course.
If it is not possible serverside, is there a possibility to transform this address on the clientside?
I thought that accessibility of http://outside.x.x:8980/MobileService/static/mobile/MobileService.json (this is working) and the services was enough for the mobile client to get it to work. But apparently this WADL is also used for something.
The WADL output is not a formally supported feature of a REST/Mobile web application. We found it useful as a 'test' for connectivity so left it in the product for debug purposes, knowing that it is not always 100% accurate and its content cannot be relied on by a client. We currently have no intention of extending any of its functionality or maintaining it. I strongly encourage you to not use it for anything other than for a connectivity test. In a real deployment scenario you should block public access.
Mike Jacobs
Ok, so the client doesn't need it to use mobile services.
The mobile client can reach the serviceURI and the catalogURI , and the services are working when tested in a browser, using the external outside.x.x:8980/MobileService url's.
Why then is the Progress Login code not working? It is working when I set the serviceURI and catalogURI to the srvdev.x.x, but not when set to the outside.x.x (except when the client is inside the intranet, then outside.x.x is working also. So somewhere the client is still trying to reach something from srvdev.x.x instead of always using outside.x.x)
This code:
var settings;
var cMsg = "ok";
try {
/* CHANGE THIS TO POINT TO YOUR SETTINGS SERVICE */
settings = MobileService_mobileresource_Settings;
pdsession = new progress.data.Session();
var loginResult =
pdsession.login(settings.serviceURI,"","", "");
if (loginResult != progress.data.Session.LOGIN_SUCCESS) {
cMsg = 'ERROR: Login failed with code: ' + loginResult;
switch (loginResult) {
case progress.data.Session.LOGIN_AUTHENTICATION_FAILURE:
cMsg = 'Invalid user-id or password';
break;
case progress.data.Session.LOGIN_GENERAL_FAILURE:
default:
cMsg = 'Service is unavailable';
break;
}
}
} catch (e) {
cMsg += "ERROR IN CATCH: " + e.toString();
console.log(e.toString());
}
if (cMsg != "ok") {
alert(cMsg);
return;
}
pdsession.addCatalog(settings.catalogURI);
This results with a "ERROR IN CATCH: Error: NETWORK_ERR: XMLHttpRequest Exception 101"
Note that I am testing the client natively on android, so there should be no cross-domain request problems.
Note:
It is working when I test the app with the "test" function in the browser from an external location. Only when I try to use the app natively, it doesn't work.
I have observed that the difference between a browser running and a device failing is the CORS support, but the mobile developers would know more about that.
The error looks like one of those typical 'tell you nothing' client javascript errors. Perhaps one of the mobile developers could assist in interpreting that.
Yes, I just found out, it is working now.
Put this in the javascript of the client, it will solve the majority of crossdomain problems:
$.support.cors = true;$.mobile.allowCrossDomainPages = true;
If that is still not working, you should set an option serverside in some Tomcat configuration:
Access-Control-Allow-Origin: *
The details of this I let to the Tomcat experts, because I am not one of them