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]

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

Another java convert

[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

Code: Select all

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

to

Code: Select all

    <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:

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

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

Code: Select all

<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]

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.