Execute same process from different session

[beek]

Hi there,
I have developed a TI process which does below
1. Identify the filtering, set the subsets of the dimension, eg Year, Scenario, product group, etc
2. Zero Off the view using those subset
3. Load the value from another cube into this cube.

It was working fine last month. However, this month, I discovered that some of the products were having 0 quantity. When I check through the TM1s log, I noticed the process only do step 1~2. Hence causing the numbers all zero.
I suspect this could due to multiple user executing the same process (with different parameter of course). However when I tried to simulate this, by using 2 different session/login, calling the same process almost simultaneously. The TI process completed nicely. It completes from step 1~3. no 0 quantity was found if the source cube does contain some data.

Anyone has any idea what could have cause the TI process only complete half way ? I suspect the user is not getting error msg, as no one reported to me they are getting any error msg.

[rmackenzie]

Anyone has any idea what could have cause the TI process only complete half way ? I suspect the user is not getting error msg, as no one reported to me they are getting any error msg.

You can try inserting AsciiOutput statements in step 2 in order that you can see what stage the process is getting to before it exits the job. For example you can set-up a counter variable which is set to 0 in the Prolog, increments in the Data tab and then written to file in the Epilog (you can use ItemReject to force it to be written to tm1server.log). If the output of the counter is 0 then there is something wrong with the way you are building the view on the cube with the source data.

[Duncan P]

If instead you are tempted to write records to the same file in different tabs then don't. If you write to a file in one tab it will wipe out anything written to that file in previous tabs. One way to get round this (if you really want one file) is to write a separate file for prolog, metadata, data and epilog, and then afterwards concatenate them with the DOS copy command.

[Alan Kirk]

If instead you are tempted to write records to the same file in different tabs then don't. If you write to a file in one tab it will wipe out anything written to that file in previous tabs. One way to get round this (if you really want one file) is to write a separate file for prolog, metadata, data and epilog, and then afterwards concatenate them with the DOS copy command.

That's of course correct, but are you referring to Robin's suggestion?

If so, and if I read that correctly, the intent was just to see whether the code actually reached the data tab. Thus in the Prolog you would have

Code: Select all

l_Counter=0;

Then in the Data tab you would have

Code: Select all

l_Counter=l_Counter+1;

Then in the Epilog tab you would have either ItemReject with the value of the counter if you want it written to a standard error log, or something like

Code: Select all

AsciiOutput('C:\Temp\Testfile.txt', Trim(Str (l_Counter,12,0))); 

if you want it written to a separate file.

In that way only one file would be created but its contents would show whether the Data tab had actually been processed (in other words, whether there was any data to process); 0 if there wasn't, the number of records processed if it was. It's only the content of the variable that would alter by tab and the file would be written only once, in the Epilog.

[Duncan P]

I was hoping that OP would follow Robin's advice, which of course only writes from the epilog. However it is tempting when you come across a new tool to see all sorts of new uses for it, and I was trying to pre-empt the potential confusion if beek had started littering AsciiOutput calls all over the shop and then wondered why only the epilog was being called.

[Alan Kirk]

I was hoping that OP would follow Robin's advice, which of course only writes from the epilog. However it is tempting when you come across a new tool to see all sorts of new uses for it, and I was trying to pre-empt the potential confusion if beek had started littering AsciiOutput calls all over the shop and then wondered why only the epilog was being called.

Good point. Unfortunately that one will only be resolved when / if Iboglix gets around to providing the much-requested AsciiAppend, which doesn't seem to be anywhere on the horizon. Until or unless that happens separate files from each tab followed by a merge is the only way to go.

[beek]

Thank you guys for the suggestions. Let me summarize your suggestions. In short, you are suggesting me to put asciioutput to know where exactly the TI process stopped or failed? Eg has it even reaches the Data tab.

This is the same TI process, which all the product admins will execute when they submit their forecast numbers. It will be triggered by 6 countries x (min)15 products. I noticed in Feb, only a few products from 3 countries were having problem. I couldn't figure out they have in common. 1 of the country almost 10 products were having problem, the others, only 2-3 having problems. However, I do noticed most of this happended on the same day, which is on 28th Feb.

However, there are also records which had been copied correctly on the very same day. Hence I'm suspecting it could due to environment; like simultaneously the same process is executed by different party, or is it due to network latency, the process terminated prematurely, etc.
Are those 2 possibilities valid? Would I be able to see some "hints" from the asciioutput? I am just thinking, if the output file just end before it goes into data tab(which I supposed this is the case, based on the tm1s log I've investigated), would I be able to tell what could have caused this?

[rmackenzie]

Thank you guys for the suggestions. Let me summarize your suggestions. In short, you are suggesting me to put asciioutput to know where exactly the TI process stopped or failed? Eg has it even reaches the Data tab.

Suggestion 1 is just to put an AsciiOutput in the Epilog to output the value of a counter (which you set to 0 in the Prolog tab and increment in the Data tab) to see how many records were actually processed. Check out Alan's post for the coding detail.

This is the same TI process, which all the product admins will execute when they submit their forecast numbers. It will be triggered by 6 countries x (min)15 products. I noticed in Feb, only a few products from 3 countries were having problem. I couldn't figure out they have in common. 1 of the country almost 10 products were having problem, the others, only 2-3 having problems. However, I do noticed most of this happended on the same day, which is on 28th Feb.

Suggestion 2 is to use separate output files per data tab (e.g. Prolog_Debug.txt, Data_Debug.txt, Epilog_Debug.txt) and do separate output files. Duncan is making sure you know that you have to use separate files for each tab of the process.

If you are using the same TI for different countries and products, you are most likely using parameters in your process. Your Prolog_Debug.txt would contain all the parameters sent into the process plus any variables you set-up in the Prolog. In the Epilog_Debug.txt you might have the counter per suggestion 1 plus other outputs that will help you find the common factor between the country/ product inputs that are causing the problem.

However, there are also records which had been copied correctly on the very same day. Hence I'm suspecting it could due to environment; like simultaneously the same process is executed by different party, or is it due to network latency, the process terminated prematurely, etc.
Are those 2 possibilities valid? Would I be able to see some "hints" from the asciioutput? I am just thinking, if the output file just end before it goes into data tab(which I supposed this is the case, based on the tm1s log I've investigated), would I be able to tell what could have caused this?

The AsciiOutput output is only as useful as you define. If you have user 1 run the process with parameters to clear out and load Nigeria for boardgames and then that runs, but moments later, user 2 runs the process for Africa and all types of toy and game, then he's going to impact the action of user 1. This is the sort of information you'd be looking to track in the debug files.

[beek]

The AsciiOutput output is only as useful as you define.

Couldn't agree with you more. What should be defined is the key.
As the output file will be a lot. Hence,
1. Output into a filename which will be appended with the timestamp. (I think this is the easiest way to generate a unique filename)
2. Do as per Alan's suggestion to output the total number of records processed.

If the output file reflected 0; this could mean the

1. the data source does not contain data
2. No sufficient accesses to the specified view/filters.
Could this due to any other possibilies?

[rmackenzie]

If the output file reflected 0; this could mean the

1. the data source does not contain data
2. No sufficient accesses to the specified view/filters.

Option (2) is not going to be an explanation - see this technote

Could this due to any other possibilies?

Based on what you've said, my vote is for (1).