Admin Console API documentation?

Admin

Here's the original YouTube question from Mangesh:
https://www.youtube.com/watch?v=NOPxe2tOv6E

Hello Jay. Thanks for this video. Where can I get the documentation for different API for Admin Console? Can I access last 5 error logs using API? Thanks.

Admin

Admin Hi Mangesh. I believe you can access the Admin Console API docs along with the other Platform API docs on your TRIRIGA server:

http://[tririga_server:port][/context_path]/api/doc/p

mangesh4fre

Admin Thank you. There are no details for admin related APIs. Like /api/v1/admin. where can I get these details

Admin

mangesh4fre Hi Mangesh, after speaking with development, the Admin Console API calls are the same calls that start with the /api/v1/admin/ prefix. Those calls offer functionality that is supported by the Admin Console UI and are mostly 1-to-1, but because they're still beta, they may not support all of the functionality in the Admin Console UI. I hope this helps.

james108

Hello. I found the video very informative. However, I can't seem to get the authentication endpoint to work: I don't get a usable cookie, and the message returned by the server suspiciously has a line that says,
" > Location: https://<myserver/unauthorized.jsp "

As instructed in the video, I'm posting to the following url:
https://<myserver>/html/en/default/verify.jsp

I'm hitting a Tririga Platform release 3.6.1.3, which has the same API specs when I query the resource /api/doc/p.

Any help would be greatly appreciated.

Admin

Thanks @james108 , I'll see if I can contact the developer who helped with the original post.

Update: OK, the developer said:

Yes, you can say that API support was introduced in version 3.8 and if he can confirm which version he uses.

james108

Admin I'm assuming this means that even though I can retrieve the API documentation at /api/doc/p on platform version 3.6.1.3, the actual implementation of the api was not introduced until release 3.8 and later. Can your developer confirm? A sincerely 'Thank you' for all your help.

Admin

james108 Yes, that's what he means. 🙂

Admin

Hey @james108, here's Update #2: Something itched in my mind about this, because in the past, our fix packs have included newer features. So I did some digging...

According to the 3.6.1.3 Release Notes (from Aug 2022), the Enhancements include the Admin Console Rest API (Beta) from 3.8. So maybe we stumbled on a defect after all. Sorry that it took a while. I'll let the developer and Support (@sruch) know. Thx for finding this! Meanwhile, here are the links to the Release Notes.

Release Notes for IBM TRIRIGA Products
https://www.ibm.com/support/pages/node/1275142

Version 3 Release 6.1.3
https://www.ibm.com/support/pages/system/files/inline-files/IBM%20TAP%203.6.1.3%20Fix%20Pack%20Readme.pdf

james108

Admin Yes, please let me know if you hear anything more. (e.g., Is there maybe a "switch" I need to turn on in the console GUI?) I'm pretty sure I made all the correct calls to get authenticated/authorized as stipulated in the video...but maybe I should revisit(??). Thanks again. FYI @sruch.

james108

FYI @Admin , @sruch Here's the auth call I'm making and the verbose output (note the Location attribute in the response). I've tried successive calls to other methods with the returned cookie, with no success.

$ curl -X POST --url 'https://<myplatform>/html/en/default/verify.jsp' \
-F 'objectId=1000' -F 'actionId=1002' \
-F 'USERNAME=<username>' -F 'PASSWORD=<password>' \
-c cookies.txt --verbose
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying <myplatform>...
* Connected to <myplatform> port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server did not agree on a protocol. Uses default.
> POST /html/en/default/verify.jsp HTTP/1.1
> Host: <myplatform>
> User-Agent: curl/7.83.1
> Accept: /
> Content-Length: 464
> Content-Type: multipart/form-data; boundary=------------------------f2d3c597208dd132
>
* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Tue, 10 Jan 2023 15:07:02 GMT
< X-Powered-By: Servlet/3.1
< Location: https://<myplatform>/unauthorized.jsp
< Content-Length: 0
* Added cookie JSESSIONID="0000gWoZm2CAukwaOagClqheWd4:-1" for domain <myplatform>, path /, expire 0
< Set-Cookie: JSESSIONID=0000gWoZm2CAukwaOagClqheWd4:-1; Path=/; HttpOnly
< X-Frame-Options: SAMEORIGIN
< Content-Type: text/html;charset=UTF-8
< Content-Language: en-US
<
* Connection #0 to host <myplatform> left intact

james108

After some sleuthing I found that the authentication resource URI has changed to:

https://{ServerHostName}{:port}/{context}/html/en/default/rest/Integration

However, when I follow the authentication call with an attempt to get active users (like such):

curl -b cookies.txt --header "Content-Type: application/json"
https://<server_name>/api/v1/admin/activeUsers/list

I get the following 500 error:

{"message":"Could not write JSON: Joda date/time type org.joda.time.DateTime not supported by default: add Module \"com.fasterxml.jackson.datatype:jackson-datatype-joda\" to enable handling; nest
ed exception is com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Joda date/time type org.joda.time.DateTime not supported by default: add Module \"com.fasterxml.jackson.datatype:jac
kson-datatype-joda\" to enable handling (through reference chain: java.util.ArrayList[0]->com.tririga.architecture.admin.helper.UserHelper[\"loginDateTime\"])"}* Closing connection 0

schannel: shutting down SSL/TLS connection with <server_name> port 443

This looks like a lack/bug on the server side. Does anyone have any poetic rhetoric to add to this saga?

I'm hitting a server running version 3.8.0.1.

Admin

Hey @james108 , Update #3, here's what the developer said:

I checked out and launched applications for latest, 380X, 400X, 410X and 420X versions. Issue is there in all three versions: 380X, 400X, 410X. It is fixed with 420X. Looks like he need to upgrade to 420X to get rid of this error.

This may not be what you wanted to hear, but the issue is fixed in 4.2.0.

CC: @sruch