TM1 REST API ( Any early adopters )

[blackhawk]

RJ!,

Oh, there is another way, but I haven't found where to set this. At the moment, it seems that the REST API server is setting the property Access-Control-Allow-Origin to * (wildcard). By doing this it prevents jQuery from using xhrFields: { withCredentials: true }. If you can find where this is being set, you can change it to the server where you have your jQuery script and then withCredentials should work.

Your code should then be:

Code: Select all

function testAjax() {
   return $.ajax({
      url: "http://localhost:port/api/v1/Cubes('GL')/Views('Default')/tm1.Execute",
      method: 'POST',
      data: { '$expand': 'cells' }
      crossDomain: true,
      xhrFields: { withCredentials: true }
   });
}

I did not see though where the server configuration files are so I did not try it. In the mean time, let me see if I have a proxy app I can send you. It is just a .CS file so it is not an EXE. It should work as long as you are using IIS.

[RJ!]

No IIS, we're using the default Tomcat install that comes with TM1.

IIS is not an option as it leads to the requirement of Webshpere/Weblogic (can't remember which one is free, but we're lumped with the $$$ one) and a lot more red tape + costs which we don't have budget for.

[blackhawk]

Ok, let me see if I have a tomcat solution...

[RJ!]

Any luck Blackhawk?

[blackhawk]

RJ!

I am still working on it. I have been snooping around a bit and it seems that the port is being controlled by the admin server, but where it gets the information for how it should configure it, still is not readily available. I am starting to believe that it is a port opened by a Java servlet not hosted under some apache tomcat instance. If that is the case, there may not be a configuration file we can tweak.

I have a call into the product manager for the API, but he has been out of the country. He should be returning this week. I will keep you posted if I can get an answer.

[BrianL]

I believe the current implementation doesn't allow for any restrictions to the Access-Control-Allow-Origin.

The admin server seems to always return Access-Control-Allow-Origin set to *

However, the TM1 server itself seems like it will just echo back the value of the Origin request header (if present)

[blackhawk]

Brian,

This has been my experience as well. I am hoping this is not hard-coded and there is some way to set this value. Unfortunately finding if that is an option, doesn't seem to be readily apparent, so I put in a call to the product manager for the API.

I am hoping to hear from him soon.

[BrianL]

I'm confused then. Only the admin server sets the wildcard not the TM1 server. This shouldn't be an issue for authentication, since you don't authenticate to the admin server.

Maybe I'm just misunderstanding the problem.


Also, the developerworks (https://www.ibm.com/developerworks/comm ... icsPg=null) forum is watched by several of the developers and often gets quick response times too.

[blackhawk]

Brian,

From what I have been able to ascertain, the admin server seems to be the one initiating the port, as you can see here in the documentation: https://www.ibm.com/developerworks/comm ... figuration.

That said, there seems to be a fix out now. You need to get TM1 Server to 10.2 RP2 HF2 from fixcentral to pick up the fix.

I am going to check that out as well.

[BrianL]

The admin server has always just been a simple application that sits around and waits for a TM1 server to start up. The TM1 server will then register itself. This process is basically sending information like server name, IP address, port number, etc... to the admin server. The various clients generally connect to the admin server first, so it can provide a list of available servers. Once you've picked one the client will get the IP address, port number, etc... from the admin server and then connect directly to the TM1 server for everything else. All authenticate is done with the TM1 server.

The REST api hasn't changed this process (although it does allow you to circumvent the admin server if you already know the IP/port number/ssl config in advance.

That document describes how to setup BOTH the TM1 server (tm1s.cfg) AND the admin server (cogstartup.xml) to enable listening for REST requests. The expectation is that you would connect to the admin host to get the list of available servers (http(s)://adminhost:5895/api/v1/Servers). Then you would connect directly to the TM1 Server (http(s)://IPAddress:HTTPPortNumber/) for everything else, including authentication.


All that being said, you are correct. I forgot to check which version I was testing. There is a bug in 10.2 RP2 and there IS a fix for it in 10.2 RP2 HF2.

[blackhawk]

Ah yes! I always thought that was kind of strange, but I see now. In my tests, I never went through the admin server in that way, I have always gone direct with what I configured in the tm1s.cfg.

Thanks.

[RJ!]

Hi Guys,

Is this secure? Noticed a bit of chatter on various forums in regards to being able to be "sniffed"?
I'm assuming that making sure we use HTTPS would suffice?

Code: Select all

<script type="text/javascript">

function login() {
   var xhr = new XMLHttpRequest();
   xhr.open("POST", "http://localhost:9510/tm1web/dwrx/jsonp/TM1Service/login", true);
   xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
   xhr.onload = function() {
      var response = JSON.parse(xhr.responseText).reply;

      if(response != null) {
         var sessionToken = response.sessionToken;
         console.debug("Session token: " + sessionToken);
      }
      else {
         console.error("Login failed.");
      }
   }

   var params = "param0=localhost&param1=Planning+Sample&param2=admin&param3=apple";

   xhr.send(params);
};

</script>

Taken from the IBM Website:
http://www-01.ibm.com/support/knowledge ... login.html

[blackhawk]

RJ!

It seems that you are using HTTP not HTTPS in the code below

xhr.open("POST", "http://localhost:9510/tm1web/dwrx/jsonp ... vice/login", true);

But if you use HTTPS, then it should be secure from a network packet perspective. The other area that there would be a security issue potentially is your JavaScript code on the client side.

If you, for example, pre-set the username and password in code to allow anyone to call up the data, then a person with a debugger can watch the code and get the username and password of the account you are using. If you require a prompt, then that is much better.

[RJ!]

I was indending to set up a Login splash screen to prompt for Username & Password.

Will work on that over the next week or so.

[RJ!]

Using the code provided by IBM (inserted to the "Body" of a HTML page), below is the error I see in Chrome Developer:

XMLHttpRequest cannot load http://LocalHost:Port/tm1web/dwrx/jsonp/TM1_Dev/login.
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://LocalHost:Port' is therefore not allowed access.

Anyone know how to resolve this?
Is that code supposed to be part of the HTML Head?

[nick_leeson]

I thought your original plan was to use REST API when and what led you down to use websheets in iframe which is probably more trouble than its worth not that REST API is any better.

Ever thought of creating a json file and then using jquery / kendo / d3 visualization . Not real time but depending on how you design it , it could work for you.

[RJ!]

Hi Nick,

Yes, that is my plan...

I just need to be able to connect to the TM1 server to be able to retrieve the data.
I thought the code I provided would give me the SessionID that can then be used to used with the the REST API to retreive TM1 data?

[BrianL]

I just need to be able to connect to the TM1 server to be able to retrieve the data.
I thought the code I provided would give me the SessionID that can then be used to used with the the REST API to retreive TM1 data?

I'm pretty sure a tm1web session token is not the same as a tm1 server REST api session token.

Also, it looks like you're still having issues with cross origin resource sharing. I believe a number of browsers don't set the appropriate origin headers when using localhost. You could try using FQDN's instead.

[RJ!]

Hi Brain,

Sorry, should have clarified, I am using the FQDN, I just put "Localhost:Port" on forum posts.

The Tomcat install is on the same server as TM1 so wouldn't have thought that cross origin resource sharing would be an issue? Or does that also include changes in the Port number?

[BrianL]

XMLHttpRequest cannot load http://LocalHost:Port/tm1web/dwrx/jsonp/TM1_Dev/login.
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://LocalHost:Port' is therefore not allowed access.

This is a cross-origin resource sharing error message. Accessing a different port does in fact count as a different origin.