Discussion:
Some Basic Questions About TDI "Rest Server API"
(too old to reply)
a***@gmail.com
2019-11-27 20:43:55 UTC
Permalink
First, greetings to anyone who may remember me from ... its been a while. And congrats to those of you who are obviously still "making things work".

I have some basic questions about using the Rest Server API - this one:

https://www.ibm.com/support/knowledgecenter/en/SSCQGF_7.2.0/com.ibm.IBMDI.doc_7.2/referenceguide649.htm#restapi

My goal is very modest. I just want to write a python script that will do some basic things like
a) get all configs
b) determine if given config/AL is running
c) stop a given Config/AL
d) start a Config/AL
e) shutdown the server

By hacking around I can do some of this via 'curls' to the web.server.port, for example:

http://10.176.112.170:1098/rest/ci . --> nice JSON response.

However, I cannot figure out (from Doc) how to stop/start a Config/AL Perhaps it done with with query parms to ../control ?

If you have a whole bunch of curl examples that would be wonderful.

Also, is it possible to send Rest API requests to the 'api.remote.naming.port' ?

I ask because our environment has quite a few TDI server processes - like 30 or so. All of these have a unique api.remote.naming.port - but they also all have web.server.port=1098. (Yes, I could change that but kind of a pain.)

Thanks!
Eddie Hartman
2019-11-29 11:28:55 UTC
Permalink
Post by a***@gmail.com
First, greetings to anyone who may remember me from ... its been a while. And congrats to those of you who are obviously still "making things work".
https://www.ibm.com/support/knowledgecenter/en/SSCQGF_7.2.0/com.ibm.IBMDI.doc_7.2/referenceguide649.htm#restapi
My goal is very modest. I just want to write a python script that will do some basic things like
a) get all configs
b) determine if given config/AL is running
c) stop a given Config/AL
d) start a Config/AL
e) shutdown the server
http://10.176.112.170:1098/rest/ci . --> nice JSON response.
However, I cannot figure out (from Doc) how to stop/start a Config/AL Perhaps it done with with query parms to ../control ?
If you have a whole bunch of curl examples that would be wonderful.
Also, is it possible to send Rest API requests to the 'api.remote.naming.port' ?
I ask because our environment has quite a few TDI server processes - like 30 or so. All of these have a unique api.remote.naming.port - but they also all have web.server.port=1098. (Yes, I could change that but kind of a pain.)
Thanks!
I agree that the docs are crap :/ Trying to figure the REST api by playing with it is frustrating...

Ok, so stopping a Config Instance is simply using the DELETE method for your HTTP request when addressing the CI uri:

DELETE http://localhost:1098/rest/ci/MyConfig

However, when I tack '/al' after the ci name, I only get the first AL started (and running).

GET http://localhost:1098/rest/ci/MyConfig/al

So this returns info on a single AL running, and it appears with an instance number (not its name) - i.e. .../al/42 Doing a DELETE to this uri seems to send a shutdown to the AL. As to start an AL, still no luck.

I have sent off a request for more info on this from my old teammates who wrote the code, so hoping for some enlightenment. I'll pass it along when I get it :)

/Eddie
a***@gmail.com
2019-12-02 17:52:36 UTC
Permalink
Thanks Eddie, I will continue to poke around on this and will report what I find. We have some Java code that uses rest calls to start/stop ALs but i cannot find the source.

However, to be sure - is it correct that all Rest calls must go to the web.server.port or can they go to 'api.remote.naming.port' ?

I cannot get 'api.remote.naming.port' to work, but I could be doing something wrong for that.

Thanks, Avery
Eddie Hartman
2019-12-04 19:32:55 UTC
Permalink
Post by a***@gmail.com
Thanks Eddie, I will continue to poke around on this and will report what I find. We have some Java code that uses rest calls to start/stop ALs but i cannot find the source.
However, to be sure - is it correct that all Rest calls must go to the web.server.port or can they go to 'api.remote.naming.port' ?
I cannot get 'api.remote.naming.port' to work, but I could be doing something wrong for that.
Thanks, Avery
In all projects where we need to launch ALs via a REST Service, I have build the REST API using an AL with the HTTP Server Connector. There we do whatever auth that is needed. And I prefer to make a stateless service, so there is no need for state persistence or session management. Sub-ALs are launched either using the main.startAL() script call, or via the AL Function Component. Note that the Server Connector lets you set up an AL Pool of DataFlow sections, replete with all the Connectors you need to handle the request. You can even use Pooled Connectors for the AL Pool components, in order to limit connections to systems, or handle setting up (SSL/TLS) connections once, before the first request is received. Note that without Pooled Connectors you still get a pool, although each AL instance in the AL Pool will have its own connectors that will be initialized the first time the AL is invoked - which means the first requests can take some time.

In addition, your AL Pool may be often calling the same ALs. If these have Iterators in the Feed section then you may want to call them, wait for a result and form the response to the client. Or you can fire and forget and reply that the request was dispatched. But if you do not have Iterators in called ALs, then you can use Manual Mode when starting the AL so that on each request handling, the called AL is cycled once and connections are not closed.

Let me know if you need more information on any of this.

/Eddie
a***@gmail.com
2019-12-06 21:11:01 UTC
Permalink
Thanks Again Eddie,

But what I am looking for is an alternative to using ../tdisrvctl. I was hoping that sending Rest calls to the web.server.port could be that alternative. But even if you said "here are all the curl examples you could ever possibly need" it may not work out for me. That is b/c our servers have multiple TDI instances running - each with a unique naming.api.port but all with the same (1098) web.port.

The reason that tdisrvctl is not working for me is that I get a lot of the StackOverFlow exceptions described here:

https://www.ibm.com/support/pages/tivoli-directory-integrator-configuration-file-contains-large-number-schema-items-may-result-errors-when-exporting-configuration-file-defaultserver-and-when-using-tdisrvctl-commands-report-function

This is only for some of the TDI instances, but enough to be a real problem.

I have tried setting IBM_JAVA_OPTIONS="-Xss512m" (and other values) before calling tdisrvctl but it does not seem to make any difference. I either get the StackOverflow or just "CTGDJB001W The command did not complete successfully"

Avery
Jason Williams
2019-12-07 20:52:12 UTC
Permalink
Post by a***@gmail.com
Thanks Again Eddie,
But what I am looking for is an alternative to using ../tdisrvctl. I was hoping that sending Rest calls to the web.server.port could be that alternative. But even if you said "here are all the curl examples you could ever possibly need" it may not work out for me. That is b/c our servers have multiple TDI instances running - each with a unique naming.api.port but all with the same (1098) web.port.
https://www.ibm.com/support/pages/tivoli-directory-integrator-configuration-file-contains-large-number-schema-items-may-result-errors-when-exporting-configuration-file-defaultserver-and-when-using-tdisrvctl-commands-report-function
This is only for some of the TDI instances, but enough to be a real problem.
I have tried setting IBM_JAVA_OPTIONS="-Xss512m" (and other values) before calling tdisrvctl but it does not seem to make any difference. I either get the StackOverflow or just "CTGDJB001W The command did not complete successfully"
Avery
In regard to the StackOverFlow issue, if you are on the latest fixpack for 7.1.1 or 7.2, have you using this new property?

**From 7.1.1.9 README*
The new property com.ibm.di.suppressSchema=true will not save schema items in the configuration file.
The schema items are mainly used for building the solution. When an attempt is made to transfer with RMI a TDI configuration file having large number of schema items, a stack overflow error may be thrown.
This could happen e.g. between the Configuration Editor and the server, or between the server and AMC.
See http://www.ibm.com/support/docview.wss?uid=swg21623396. for description

## ----------------------------------
## Suppress Schema
## ----------------------------------
com.ibm.di.suppressSchema=true
***

Loading...