Finally got this hooked up and working.
First off, if you are using an IBM i, you MUST setup a Windows / Linux web server to act as a front end.
I followed these instructions and it went well.
https://docs.lansa.com/14/en/lansa085/i ... 0020ws.htm
Secondly, after talking with support, I think the API Definition is pretty much ALL meta data used to build the Swagger / Open API docs. However where those docs get generated is still unknown.
IMHO, the way the API Definition is displayed, it implies you are defining your API; complete with security and object definitions. This does not seem to be the case. I've also had numerous IDE crashes when trying to enter a route/path parameter. If you define security requirements, parameters etc. you will not get anything in the code, YOU MUST code it all your self, i.e. reading / validating header params, path params etc.
The only thing of interest is the Path which allows you to map a URL to a Server Module and Routine. After digging through the file system (again no docs on this), a webmodules.conf file is generated in the LANSA_install/run/conf folder. This conf file is a JSON file that contains the mappings.
NOTE
If you edit this file yourself, the next time you compile your Server Module, your changes will be overwritten! This brings up a catch however. If you try to add a parameter to the the path using the API Definition the IDE crashes (at least for me). If you add the parameter to the conf file, your changes disappear when you compile the Server Module.
Here is my file with the demo maps and the two mappings I added at the bottom, after the module has been compiled
Code: Select all
{
"-auto-alias": false,
"default": {
"language": "ENG",
"partition": "dem"
},
"realms": {},
"map": [
{
"aliases": [
"/xContact/{ContactId}"
],
"method": "Get",
"module": "XDEMOW_94",
"routine": "GetContact"
},
{
"aliases": [
"/xContact/{ContactId}"
],
"method": "Put",
"module": "XDEMOW_94",
"routine": "PutContact"
},
{
"aliases": [
"/xContact/{ContactId}"
],
"method": "Delete",
"module": "XDEMOW_94",
"routine": "DeleteContact"
},
{
"aliases": [
"/xContacts"
],
"method": "Get",
"module": "XDEMOW_94",
"routine": "GetContacts"
},
{
"aliases": [
"/xContacts"
],
"method": "Put",
"module": "XDEMOW_94",
"routine": "PutContacts"
},
{
"aliases": [
"/sys/offices"
],
"method": "Get",
"module": "MGSOFCS02",
"routine": "GetOffices",
"partition": "sys"
},
{
"aliases": [
"/sys/offices/{number}"
],
"method": "Get",
"module": "MGSOFCS02",
"routine": "GetOffice",
"partition": "sys"
}
]
}
The other thing to note, is that this file
DOES NOT get generated automatically when you check in the server module. You must copy this file to your server (in my case the IBM i) with the same path.
After you have established the web server and it can successfully talk to your application server (IBM i) and you have uploaded the webmodules.conf file to the IBM i, you should be able to access the path defined in the module.
Don't forget to enable the port on your web server! I had to create a rule to allow inbound 8080 requests.
Now I can go to my web server url such as
http://mywebserver:8080/sys/offices/1002 and it will invoke the GetOffice Routine in the MGSOFCS02 Module.
Hope this helps,
Joe
BTW: I really hope LANSA takes this a step further and
- improves the documentation
- improves the API Definition tab
- provide hooks / resources to do automatic security validation, documentation, field / parameter binding etc.