TM1 Forum

Hi Guys,

I am implementing Email Notification for TI Process Execution status.

I need to to give on which server this process has been executed,right now i am hardcoding Server name.is there any TM1 function to pull the Server name in TI Process(like TM1USER)?.

Thanks in Advance.

Regards,
Nata

nataraja.pl@tcs.com wrote:Is there any TM1 function to pull the Server name in TI Process(like TM1USER)?.

No, but you can simulate one by storing the server name in a cube and doing a CellGetS.

Thnaks tomok, i thought of this but i need to change the server name on cell when we moved to other environment.

Regards,
Nata

Yes, but you only need change it in one place rather than in all your TI processes.

Unfortunately tomok's suggestion is the best workaround. There is no TI or rule function for finding out the name of the server you are on.

The tm1s.cfg file holds the server name. Although it's not actually mandatory, it's standard practice to place this in the server directory. You could then have a TI read the cfg file to pick up the server name.

David Usherwood wrote:The tm1s.cfg file holds the server name. Although it's not actually mandatory, it's standard practice to place this in the server directory. You could then have a TI read the cfg file to pick up the server name.

This is generally what I do, have a TI read the tm1s.cfg file and populate a string cell in a control lookup cube automatically. This requires that the tm1s.cfg file is in the data directory and takes advantage of the fact that if you only specify a file name with no file path as the data source for a TI process then TM1 assumes the same root directory as the data directory.

Note:
- In some (rare) instances the windows environment may necessitate qualifying full path references and this won't work (also applies to passing targets to ExecuteCommand).
- tm1s.cfg being in the same place as the data directory is probably true of 90%+ of TM1 models out there but not for everyone, some developers have a preference to have a different configuration directory (and with CX you don't have a choice unless you change things it will be a separate directory)
- if you do have the config file in the data directory then it is a good idea to exclude copying the tm1s.cfg file when backing up to avoid any potential errors when restoring or migrating

In some (rare) instances the windows environment may necessitate qualifying full path references and this won't work (also applies to passing targets to ExecuteCommand).

We are running into this problem, on 9.5 running on windows 2003 R2 64x and are unable to read the file from the TI process. If you edit the TI it says it can't find the file, however if you browse to it, then delete the path then the process works, but when running the TI without editing the process does not read from the file...

Anybody got any ideas?

Thanks

failurehappening wrote:

In some (rare) instances the windows environment may necessitate qualifying full path references and this won't work (also applies to passing targets to ExecuteCommand).

We are running into this problem, on 9.5 running on windows 2003 R2 64x and are unable to read the file from the TI process. If you edit the TI it says it can't find the file, however if you browse to it, then delete the path then the process works, but when running the TI without editing the process does not read from the file...

I'm not sure that this is what your problem is, but it's worth looking at; in versions up to 9.0 you could use a mapped network folder as the path to a file. I noticed that that no longer worked in 9.1; you had to use either the UNC path (that is, in the format \\ServerName\Folder\Name\RestOfPath\Filename.cma) or, if the file is located on the server, it's local drive name (like D:\FolderName\FileName.cma). I'd imagine that it's the same in 9.4/9.5. Probably best to use the UNC path if possible and see whether that works.

Thanks for the reply, but unfortunately I can't use UNC paths as we are using multiple instances with different data directories.

Our main data directory would be e:\data\tm1\instance1, but we have many test instances, upto instance6 (don't ask why.. this is what happens when project planning is done with little technical input!)

I'm trying to get the instance that is currently running so that in the combined log files I am able to identify which instance wrote out which line.

Is it possible to execute a batch file from the data directory that could return the path to TM1?

I think you're going to have to clarify exactly what you're trying to do here because I have no idea what great chunks of your reply are intended to mean.

failurehappening wrote:Thanks for the reply, but unfortunately I can't use UNC paths as we are using multiple instances with different data directories.

What difference does that make? Each instance will have a different data directory, and a different log file directory. Each one should be able to be represented by a UNC path.

failurehappening wrote: I'm trying to get the instance that is currently running so that in the combined log files I am able to identify which instance wrote out which line.

What do you mean "in the combined log files"? Each instance will have to use its own log file. It will get a lock on the relevant file(s) so that no other instance can use them. The only way you can have combined log files is if you combine them yourself after the fact. Also, which log files? The transaction logs? The Message logs? The error logs? Some logs that you're writing yourself from an AsciiOutput or TextOutput statement?

failurehappening wrote:Is it possible to execute a batch file from the data directory that could return the path to TM1?

If you're consistent in naming your data and error log directories (or become so, by including the server name as part of your paths), why not simply call the GetProcessErrorFileDirectory function and parse the relevant content from that?

Hi Alan

Thanks for the response, even if my question didn't make sense! You have solved my issue, which I will try and doco here... let me know if this does make sense!

We as a team (6) have a single integrated development instance with the server name of TELCO, each developer has their own instance to "play" in which is named their name.

We have a number of concurrent releases being developed at the moment, each at a different stage in the SDLC, so each of these require their own instance in the test environment, with different deployments being sent to different environments. These all write back to a common custom log file during processing that indicates the start and end time of each process.

When multiple instances are running concurrently, they all out put the same so you get something that looks like this:

2011-03-22 16:43:37 Process 1 Started
2011-03-22 16:44:31 Process 1 Started
2011-03-22 16:45:56 Process 1 Started

2011-03-22 16:53:37 Process 1 Completed
2011-03-22 16:54:31 Process 1 Completed
2011-03-22 22:55:56 Process 1 Completed

with no way of knowing which one took a really long time

Thanks to the info you gave I was able to update a control cube with instance, without having to update it manually everytime an instance was copied by adding a call to this process at the beginning of the overnight process: Then in the log file writing process adding the server name to the beginning of each line:
So Now my combined error log looks like this:

TELCO1 2011-03-22 16:43:37 Process 1 Started
TELCO2 2011-03-22 16:44:31 Process 1 Started
TELCO3 2011-03-22 16:45:56 Process 1 Started

TELCO2 2011-03-22 16:53:37 Process 1 Completed
TELCO3 2011-03-22 16:54:31 Process 1 Completed
TELCO1 2011-03-22 22:55:56 Process 1 Completed

Thanks again for the help

failurehappening wrote:We as a team (6) have a single integrated development instance with the server name of TELCO, each developer has their own instance to "play" in which is named their name.

We have a number of concurrent releases being developed at the moment, each at a different stage in the SDLC, so each of these require their own instance in the test environment, with different deployments being sent to different environments. These all write back to a common custom log file during processing that indicates the start and end time of each process.

I hate to break it to you but you do not have six separate "instances" of TM1. You just have six different developers createing cubes, dimensions and TI processes on a single instance of TM1. If you are all working together on creating a unified solution this is fine, albeit somewhat difficult with that many moving parts. If all these "instances" as you call them are to be separate solutions you probably shouldn't do it this way. You should consider creating separate services for each to keep from bumping into each other. As long as your're not running CX that is perfectly allowable.

My read was that they do have 6 separate dev TM1 database instances running. Quite why they are doing this escapes me and I would be interested in how the custom log file is being created obviously they can't be ascii outputting to a common file as this woudl just get constantly overwritten, so I'm guessing it is either discrete files which are getting concatenated by a downstream process or else they are logging to an RDBMS with table inserts (which I wouldn't recommend due to the possibility of performance constraints.)

Used successfully in Planning Analytics:

use a subprocess

Server Data Source : ..\tm1s.cfg

Delimiter : =

and then find out the DataBaseDirectory and ServerName

There is a free solution from me.

just put this process on startupchore in the config.

after exec you get a dimension sys_ServerParameters with attributes cube where places all params in pParamsList variable.