TM1 SDK JavaExtensions ( Any early adopters )

[uchow10]

Hi All,

I have been working with the new TM1JavaExtensions and although it seems almost every TI function is supported in Java I am still struggling to perform one of the basic TI functionality which is pulling data from a cube view.

I believe in the old Java API we can declare TM1 objects (cubes, views, etc...) and there is a function called "getView()" as referenced in this post (http://www.tm1forum.com/viewtopic.php?f=3&t=10054) which one can retrieve and handle in the Java environment as its own object and convert it to an array

However in the new SDK is there an equivalent function?

Lets say I create a cube view and i want to pull data from that view in Java and load it to another cube, how would I go about doing that? I have actually tried calling my java program from the data tab of the TI as a workaround but the context switching between the two environments nearly doubled my TI execution time so I was wondering if anyone has a better suggestion?

Thanks a lot!

[nick_leeson]

I have had a good play with the new TM1 SDK and whilst is perfect for building in mathematically intensive calculations like IRR , Black Scholes or moving averages. You will find that you will not get a lot of value doing stuff that something TI will do naturally. String comparison are also is one perfect are where this could improve on performance.

A Bedrock style Library on JAVA is being built by one of the major partners but from a practical point of view where most of the larger companies are still on 9.5.2 there is still a lot of work to do on this front.

[uchow10]

Nick, thanks for the feedback. I agree with you that there's still much to be done in this area but I think there is some value in trying to utilizing Java to replace TI and I will try to see if I can get this to work.

There are two possibilities I am looking into now:

1. I was wondering if I can still use the old TM1 library in conjunction with the new one. That way I can leverage both the TI supported java functionality and create TM1 objects in java. Does anyone know where I can get the old java ti library?

2. Utilize the REST api and parse the GET response from TM1 and use that as my "getview()" function. Has anyone done this before? I am a little unfamiliar with JSON and not certain if this can be done.

Thanks a lot!

[nick_leeson]

Been playing around with REST API and I am nearly there so watch this space.

[Mike Cowie]

Hi Uchow10:

First, I don't think the description of Java Extensions on the IBM DeveloperWorks site is accurate:
"Most TurboIntegrator functions are supported in Java and can be used like any other Java method. You can create TurboIntegrator processes with Java and use Java’s libraries to further expand the capabilities of IBM®Cognos®TM1®"

Java Extensions can't really be used to create a TI process. They can be used to create a class, using Java, that can be called from a TI process.

I'd like to understand why you need to pull data from a cube view in a Java Extension when a cube view can be a data source of a Turbo Integrator process. If it's to extract data from another TM1 server instance then I can maybe see where you're going with this, but if not I don't know why you'd try to pull in cube view data with a Java Extension. If you do pull in a large number of "records" via a Java Extension then there is no way to easily return that directly to your TI process, since TI currently only lets you return a string or numeric value from a Java Extension. You would instead need to write that data somewhere (file, relational DB, etc) as part of your Java Extension and then, perhaps, return the path to that file to TI and use it to change the data source location used by the TI process to load in that data.

In general, because you have access to nearly all TI functions in Java Extensions you should not need to access other TM1 APIs, whether it be the TM1 Java API or new REST API, from Java Extensions. Java Extensions are still quite powerful, but I don't think are meant to replace TI process writing as we know it today.

Regards,
Mike

[lotsaram]

In general, because you have access to nearly all TI functions in Java Extensions you should not need to access other TM1 APIs, whether it be the TM1 Java API or new REST API, from Java Extensions. Java Extensions are still quite powerful, but I don't think are meant to replace TI process writing as we know it today.

Are you sure? Because I can imagine a lot of "common task" type stuff being written in Java and then effectively called as a function from TI.

[Mike Cowie]

In general, because you have access to nearly all TI functions in Java Extensions you should not need to access other TM1 APIs, whether it be the TM1 Java API or new REST API, from Java Extensions. Java Extensions are still quite powerful, but I don't think are meant to replace TI process writing as we know it today.

Are you sure? Because I can imagine a lot of "common task" type stuff being written in Java and then effectively called as a function from TI.

Lotsaram:

The OP seemed to be trying to rebuild an entire TI process, including data source access, with a Java Extension. This comment was directed at that and an earlier point: this doesn't provide an alternative way to create an fully-functional TI process. You still have to build TI processes in order to use Java Extensions. Can Java Extensions replace some processes that have no data source and just Prolog or Epilog script? Absolutely. Should everyone start trying to rebuild/refactor their existing TI processes to use Java Extensions? It really depends on the process/business objective.

Make no mistake - I'm a huge fan of Java Extensions. Being able to (finally) extend TI with reusable functions developed in Java is awesome (hopefully something similar in Rules isn't far behind). I'm looking forward to Java Extensions right away for things like string manipulation (hello, Replace function) and for similar, reusable, snippets that either get used often (the "common task" stuff) or are a royal pain to develop in TI script because you don't have access to arrays, objects and other modern programming language constructs. It's also going to be handy for those situations where we need to reach outside of TM1 to a source of data/system that TI can't otherwise interface with, which in the past we ended up doing with things like ExecuteCommand calling some external application. I also love that you can write messages directly to the Server message log with Java Extensions.

There's a risk, though, that Java Extensions get applied where they aren't really needed, adding unnecessary complexity to a TM1 application. Or, worse, they could get misused by dodgy consulting firms to make a customer wholly dependent on their services by overusing Java Extensions in TI process logic, which is much less visible to the customer without access to source code and someone who is familiar with Java. These aren't new problems, but the consequences could be much more difficult to correct than the sorts of "suboptimal" TM1 implementations that you, presumably, and I get tapped to do a 3rd party review/audit of on a regular basis.

Regards,
Mike

[jim wood]

There's a risk, though, that Java Extensions get applied where they aren't really needed, adding unnecessary complexity to a TM1 application. Or, worse, they could get misused by dodgy consulting firms to make a customer wholly dependent on their services by overusing Java Extensions in TI process logic, which is much less visible to the customer without access to source code and someone who is familiar with Java. These aren't new problems, but the consequences could be much more difficult to correct than the sorts of "suboptimal" TM1 implementations that you, presumably, and I get tapped to do a 3rd party review/audit of on a regular basis.

Excellent point Mr Cowie. While the Java Extensions add another string to their bow it also adds another to those with better practices that will end up solving it for the same customers.

[uchow10]

Hi Uchow10:

First, I don't think the description of Java Extensions on the IBM DeveloperWorks site is accurate:
"Most TurboIntegrator functions are supported in Java and can be used like any other Java method. You can create TurboIntegrator processes with Java and use Java’s libraries to further expand the capabilities of IBM®Cognos®TM1®"

Java Extensions can't really be used to create a TI process. They can be used to create a class, using Java, that can be called from a TI process.

I'd like to understand why you need to pull data from a cube view in a Java Extension when a cube view can be a data source of a Turbo Integrator process. If it's to extract data from another TM1 server instance then I can maybe see where you're going with this, but if not I don't know why you'd try to pull in cube view data with a Java Extension. If you do pull in a large number of "records" via a Java Extension then there is no way to easily return that directly to your TI process, since TI currently only lets you return a string or numeric value from a Java Extension. You would instead need to write that data somewhere (file, relational DB, etc) as part of your Java Extension and then, perhaps, return the path to that file to TI and use it to change the data source location used by the TI process to load in that data.

In general, because you have access to nearly all TI functions in Java Extensions you should not need to access other TM1 APIs, whether it be the TM1 Java API or new REST API, from Java Extensions. Java Extensions are still quite powerful, but I don't think are meant to replace TI process writing as we know it today.

Regards,
Mike

Hi Mike,

The reason I was pursuing this was actually really to see if I can actually replace TI with Java Extensions entirely but I very much agree with all the points that you've brought up. As you mentioned its actually very possible that given such a powerful feature, one could take a TM1 model and obscure all the TI process logic in Java adding another layer of complexity to a TM1 application.

To your point, I do not think this will replace traditional TI process writing anytime soon. But given the new tools, REST and Java Extensions, I do actually think its possible to create TI processes outside the Architect or Performance Modeler environment albeit not as easy. Whether or not that may be the direction we are heading I do not know but I do believe the possibility is there.

[saltRR]

I#m sorry for picking up this Disscusion, but I wanted to pick up a question, that was mentioned before here

1. I was wondering if I can still use the old TM1 library in conjunction with the new one. That way I can leverage both the TI supported java functionality and create TM1 objects in java. Does anyone know where I can get the old java ti library?

I have both libraries and both on their own are working fine.
My question is now if it is possible to combine both the Java API and the Java extensions. Because if i try to use the classes like TM1bean from the Java API in a Java extension function, TM1 tells me that there is a class loader error.
I couldn't find anything on this topic because both libraries a mixed up a lot in some posts.