cubewise-code / tm1py

TM1py is a Python package that wraps the TM1 REST API in a simple to use library.
http://tm1py.readthedocs.io/en/latest/
MIT License
190 stars 109 forks source link

Success every 2nd run #271

Closed dfrankenCW closed 4 years ago

dfrankenCW commented 4 years ago

HI all

I have a head-scratcher (for me) ...

I have a Tm1py python code that executes 100% every time when running it from python or the command prompt.
Calling it from Tm1 (Epilog in a TI) works 100% every time.

BUT

Then I added a cube clear in the prolog and now by success rate is 50% - thus every 2nd run there is just no result.
I created a wrapper process calling the cube clear and execute python separately with the same result. I inserted a waiting process after the cube clear (30 seconds) - this also did not change the result.

Any idea on why I see this behavior?

Thanks

scrumthing commented 4 years ago

What does the code do? What is the error message? You should be a bit more specific. :-)

dfrankenCW commented 4 years ago

The Tm1py code evaluates attributes from 2 dimensions and does a compare on them - thus a "Find the best Match" algorithm. The result is then written back to a cube. But the result set in Tm1 needs to be cleared before each execution.

There is no error message - that is the problem - according to all log files the process executes successfully - but no result is seen in the cube. It is as if the result write happened before the cube clear. And only every 2nd run.

MariusWirtz commented 4 years ago

TM1py never fails silently. When any REST operation fails in TM1py (e.g. a process fails or the MDX has a typo) you will get a TM1pyException.

Perhaps when you execute it through ExecuteCommand from TI, you just don't notice the error. Perhaps try to wrap your code in a try, except block and log the potential error into a log file.


import logging

from TM1py.Services import TM1Service

logging.basicConfig(
    filename="tm1py.log",
    format='%(asctime)s - TM1py - %(levelname)s - %(message)s',
    level=logging.INFO)

try:
    with TM1Service(address="", port=12354, ssl=True, user="admin", password="banana") as tm1:
        tm1.server.get_message_log_entries()

except Exception:
    logging.exception("Fatal error in main loop")
MariusWirtz commented 4 years ago

Also please make sure you use the execute_process_with_return method instead of the execute method. The IBM REST API exposes two methods to execute processes. The execute_process_with_return will throw a TM1pyException even at a minor error.

It's easier to deal with. For the execute method you have to parse and understand the response JSON yourself.

rkvinoth commented 4 years ago

@dfrankenCW

I could somewhat understand the issue here. The wrapper process that is calling the Cube clear is not working as expected. It is clearing the cube after TM1py has loaded the data into the cube.

This is because of the commit difference between the TI process and the data load via REST API.

First of all, lets make sure your TM1py code is doing the work as expected. So basically try to write the output to a csv file and check if the file has data (also check if it has required data).

Secondly, move the cube clear process into the TM1py code

If you don't feel like moving the cube clear into TM1py, then push the data to a csv file and perform the update to the cube using a TI process instead of directly updating it via TM1py.

rclapp commented 4 years ago

This is quite common when you have 2 sessions doing work in parallel and the commits don't line up. Especially if you do an execute command with a wait (1). It works like this.

1) TI runs 2) cube clear data or zero out 3) the change is held in an uncommitted state, due to parallel interaction. 4) python is called 5) python data is committed --- at this point the cube is in 2 states-- --- the real, queryable, data is that written by python --- --- the cube overlay produced by the TI has the cells as empty 6) clear data is committed back to the cube replacing the data that was written there 2nds ago

The 2nd time you run it, the clear does not produce an overlay because the cells are already blank, therefore the python works.

Ryan Clapp AWS Business Systems Sr. Manager

Sent from my mobile device

On Jul 6, 2020 3:42 AM, Vinoth Kumar Ravi notifications@github.com wrote:

@dfrankenCWhttps://github.com/dfrankenCW

I could somewhat understand the issue here. The wrapper process that is calling the Cube clear is not working as expected. It is clearing the cube after TM1py has loaded the data into the cube.

This is because of the commit difference between the TI process and the data load via REST API.

First of all, lets make sure your TM1py code is doing the work as expected. So basically try to write the output to a csv file and check if the file has data (also check if it has required data).

Secondly, move the cube clear process into the TM1py code

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/cubewise-code/tm1py/issues/271#issuecomment-654156515, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEK7GZW2DI45VJX6V4SACLTR2GS65ANCNFSM4ORLNF4Q.

dfrankenCW commented 4 years ago

Thanks, Ryan Make perfect sense now.

I moved the Clear to the python script and now the process execute as it should.