Consuming an AIM REST API from with AIM app

johntalbott

Is anyone consuming an AIM REST API from "within" the same AIM app?

I tried previously in v7 and tried again in v8.1. The API works in that I can retrieve the JSON response as expected.

BUT the call to the REST service creates a new browser session (cookie) which causes the original app session (cookie) to expire. It requires logging into the app again.

Any suggestions?

Jaymer

What are you trying to do... just Generate some JSON?

johntalbott

The goal is to decouple the UI from the AIM processes and data actions (CRUD) in a very simple, straightforward manner.

PointsWell

Would you not be better using the java API for that?

BobK

PointsWell wrote
Would you not be better using the java API for that?

Another java convert :lol:

tford

The goal is to decouple the UI from the AIM processes and data actions (CRUD) in a very simple, straightforward manner.

John,

If this is the goal, is there a reason why you don't have two AwareIM BSVs and have one provide data to the other via REST service(s)?

UnionSystems

Hi John,

Did you ever find a solution for this? We have a Kendo Autocomplete widget woking nicely with its datasource being an AwareIM REST service but as you point out calling the REST service overwrites the browsers JSESSIONID cookie so the original SESSION expires.

johntalbott

Unfortunately I haven't.

Vlad - Is there a way to work around this issue?

UnionSystems

If you extend web.xml from

    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>

    <session-config>
        <session-timeout>30</session-timeout>
        <cookie-config>
        <name>${user.name}XYZ</name>
        </cookie-config>
    </session-config>

Session Cookie name is myServerUserNameXYZ instead of the default JSESSIONID, where myServerUserName is the name of the server user.

Could we replace ${user.name} with something thats mapped to the BSV being called? We would than have BSV specific session cookies on the same server and not have timeouts from the same browser (and be able to ajax call AwareIM REST)? Is this possible in web.xml (and not something that will break AwareIM)?

UnionSystems

I think I have found a workable solution for this issue:

Enable CORS through your AwareIM Tomcat web.xml configuration file
Create an alias name for your AwareIM server
AJAX your REST service using this alias name

Enabling CORS
Add following before the closing </web-app> tag in Tomcat\conf\web.xml

<filter>
    <filter-name>CorsFilter</filter-name>
    <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>CorsFilter</filter-name>
    <url-pattern> /* </url-pattern>
</filter-mapping>

Note that this enables ALL domains to access server. Should be more restrictive on a public facing server but OK for development and VPN? You need to restart AwareIM (Tomcat) for this to take effect.

Creating Alias Domain

Create an Alias in DNS or edit your local hosts file.

AJAX this Alias Server

Your javascript should call the Alias server name.

Jaymer

Dave
I think it should be easier than this.
I started another thread on this - without realizing this thread was here.

I think Support can bypass JSESSIONID creation on a REST request.
Its just a line to add in the code.
This would solve this issue.

aware_support

Why do you need to call REST API? This is totally unnecessary. (and not supported)

If you want to decouple the UI from the backend just use the Aware IM XML interface that Aware IM UI code itself uses. The code is available in the AwareIM/Tomcat/webapps/AwareIM/aware_kendo directory.

If you are smart enough to decouple the UI from the backend you should be able to figure out how the Aware IM code does it. 😃

And also,
DO NOT MESS WITH JSESSIONID

johntalbott

aware_support wrote
Why do you need to call REST API? This is totally unnecessary. (and not supported)

If you want to decouple the UI from the backend just use the Aware IM XML interface that Aware IM UI code itself uses. The code is available in the AwareIM/Tomcat/webapps/AwareIM/aware_kendo directory.

If you are smart enough to decouple the UI from the backend you should be able to figure out how the Aware IM code does it. 😃

And also,
DO NOT MESS WITH JSESSIONID

For the majority of base web application functionality, AIM generally offers a quick way to get there. However, there are instances where using Init or Render scripts for custom UI functionality is way more work than just building the functionality from scratch.

For those scenarios, it seems that the best you can offer is a suggestion to dig through ten's of thousands of lines of undocumented AIM JS code?

I'm clearly a masochist, because I have done exactly that as there wasn't another alternative. It certainly wasn't fun or efficient. In a fraction of the code and in 1000th of the time, the same thing could have been done with a custom UI living within the AIM UI framework making REST calls to an AIM service.

This reminds me of the banana / gorilla problem ... "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

Jaymer

My entire need for my approach is because I need Radio Buttons in a grid.
And since AIM doesn’t support that, I needed to think outside the box.
And I have a perfect solution (actually, better than I could do IN Aware if it DID support radio buttons), except for this SessionID issue.

aware_support

I still don't understand what REST has to do with it. Why on earth radio buttons in grids require REST???

About having to go through thousands lines of code. All you need to understand is how Aware IM UI "actions work". There is the base class AwareApp.ServerCallAction and about a few dozen of descendants that do everything - from reading/writing an attribute to saving inline edits of a grid. Just look at them and use them or create your own descendants. It is not that hard - certainly not harder than calling REST and parsing JSON.

Once again, REST in Aware IM IS NOT SUPPOSED TO BE CALLED FROM THE UI.

Jaymer

Dave,
I had a Skype convo with Vlad.
In it, he said 1 important thing:
"When you make a normal REST call from Aware IM it is done from the backend - there is no UI involved. If you are calling from the UI it's a lot more complicated, like I explained. "

Well, I think he misinterpreted this post from the very beginning.

A "normal" REST call from Aware (like calling WeatherAPI) is done in a Rule with "REQUEST SERVICE".
This is NOT how I'm doing it.
Am unclear what John (OP) meant.
And I know thats not how you are doing it, since its part of stuff inside Kendo HTML, that you've injected via Init/Render script.

But if he's now reading this correctly, then he's thinking we are doing REQUEST SERVICE - And I'll buy that, that you can't call your same app from a Rule in that same app.

So, what i'm trying to point out is that since we are NOT calling "ourselves" that way, the calling script DOES NOT NEED a JSESSIONID generated (which cancels the prior one) and returned to it with the content.
Here's is the Response Header from Aware to a Postman call:

Set-Cookie:"JSESSIONID=60493D89C5B28AF52EF01684453EA166; Path=/oem; HttpOnly"
Content-Type:"application/json;charset=UTF-8"
Transfer-Encoding:"chunked"
Date:"Thu, 26 Sep 2019 14:34:06 GMT"

Since its possible to override this cookie, and since we dont need it, then that should be our focus.

aware_support

Once again to recap this for relatively advanced users:

If you want to communicate to an Aware IM backend from Javascript (i.e from the UI front end which is part of the UI of your Aware IM application), then there are two ways to go about it:

1) You can go directly to a URL (for example, to call an Aware IM REST service)
2) You can use the Javascript XMLHttp object (which is the basis for the AJAX technology)

When an Aware IM backend receives a call from the UI it has to identify the current user. Tomcat does it by using a special parameter called JSESSIONID. So ALL requests from the UI must have this parameter, otherwise the backend loses the user making the call.

Approach in 1) does not include this parameter unless you get it from the browser cookie yourself and provide it as part of the call. Approach 2) AUTOMATICALLY does it because the XMLHttp object collects browser cookies automatically. Note, that this is not an issue when a REST service is called from rules (REQUEST SERVICE) because the call is initiated from the backend and there is no user involved.

So the right way to go is approach 2). Note that you do not have to use XMLHttp object directly as Kendo UI and Aware IM has a lot of more convenient wrappers around this object.

In Aware IM there are two ways to communicate with AJAX:
a) For simple requests that send some parameters to the backend and return the result (for example to read the value of an object's attribute) you can use the Actions framework that I have mentioned before
b) If you want to run queries that return multiple records you need to use Kendo UI data source objects that communicate with the Aware IM backend. If you look at the aware_kendo/parsers directory you will find examples of this - for example, customLayoutParser uses a datasource to communicate with an Aware IM backend and display the results as a "custom query" (Kendo UI ListView widget).

One day we will document this in detail. In the meantime you can study the code.

Jaymer

aware_support wrote
1) You can go directly to a URL (for example, to call an Aware IM REST service)
<snip>
Approach in 1) does not include this parameter (JSESSIONID) unless you get it from the browser cookie yourself and provide it as part of the call.
<snip>
So the right way to go is approach 2)

I don't see why Approach 1 is not valid. You prefer # 2, but you already said I can use # 1.
If I go to a URL right now that activates an Aware REST service, it sends me data back. I did not have a JSESSIONID, nor did ANY user out there consuming my REST service. No one is "providing it as part of the call" and yet I still got a reply.

The only issue is that the programming servlet that responded to the REST request generated a JSESSIONID when it didn't need to.
And you can see from the Tomcat manager that even if it creates a JSESSIONID (which it did), its not keeping it as an active session.

Jaymer

@Dave
whats your status on this type of activity now?
whats with the autocomplete widget you referred to?
J