Unlocking All nodes in Applications Web Via TI

[TrevorGoss]

Hello all,

one of our customers biggest pains is after there month end process, they have to unlock all of there nodes in a workflow inside applications web. They have to unlock each and every locked cell one at a time. With hundreds of cells to unlock, it becomes labourious, often with them asking us to help.

i have created a process which deals with this. This process consists of a model inside Apps Web, which contains a picklist of all the models on a server (apart from itself). The end user picks a model and commits the node. This commit event calls a TI which picks up the picklist choice, passes that picklist choice to another TI, which works out the application ID and then passes it onto the final TI which unlocks every single locked node in the worklow, along with removing the owners.

The TI that unlocks all the nodes is:

Code: Select all

### Get the size of the dimension of the application
vDimSiz = DIMSIZ('}tp_tasks}' | pAppId);

### counter
x = 1;


### Loop around the dimension, get the state of each node in the dimension
### and if that state is not a 0 ie is not available, then make it available 
while (x <= vDimSiz);

	vDim = DIMNM('}tp_tasks}' | pAppId,x);
	vGetState = CellGetS('}tp_application_state}' | pAppId,vDim,'State');
	if(vGetState @<> '0');

			CellPutS('0','}tp_application_state}' | pAppId,vDim,'State');
			CellPutS('','}tp_application_state}' | pAppId,vDim,'CurrentOwner');
			CellPutS('','}tp_application_state}' | pAppId,vDim,'CurrentOwnerID');
	EndIf;


x = x + 1;
End;

This script loops around the 'tp_application_state' cube and the 'state' element and everytime it finds a cell that is not 0, ie 'available' it makes it 'available', along with getting rid of the CurrentOwner and ID.

Once this process has finished, you open up the workflow inside applications web and every single node is now available.

We asked IBM about this a couple of years ago, not with the same process but a manual changing of the control cube data, and IBM got back to us saying they would not support it.

My questions are as follows:

does anyone here explicitly reject this idea? Would anyone advise us not to take this approach?

Would anyone recommend this process? Does anyone do anything similar?

We would like to know of the risks involved and if it is worth promoting this to production and releasing to our users, it solves a problem for our customers, but if it is too risky we will not go forward with it.

Any advise would be appreciated, thanks guys.

Trevor.

[dharav]

TrevorGoss

to unlock or reset all nodes of the model for all groups for approval hierarchy at the end of the each month? is it your problem? or you just want to do it with TI?

IF You want to unlock for all groups:

First: You should do it in a second having admin rights with you. Go to web and reset for all.
Second: TI would take more time than what you can do it manually (not much still). its that fast manually.

Let me know and specify with example if your question is something different than what i replied for.

Thanks

Dharav

[TrevorGoss]

Hello dharav, thanks for the response

to unlock or reset all nodes of the model for all groups for approval hierarchy at the end of the each month? is it your problem? or you just want to do it with TI?

I want the end users of our system to be able to reset all nodes in a given model via a commit event, which kicks off a series of TIs.

First: You should do it in a second having admin rights with you. Go to web and reset for all.
Second: TI would take more time than what you can do it manually (not much still). its that fast manually.

Because we want the end users to perform this action, they will be unable to perform these steps. The TI is just as quick as the manual restart and can be performed by someone without admin access.

The process itself works, the end user picks a model from a picklist, runs the commit event thereby resettting each node inside entire hierachy. Our main concern is the possilbe risks involved in running a TI on a control cube, especially a control cube which controls applications web. We would like to know if anyone would reccommend, warn against, or reject this process.

Thanks.

[lotsaram]

The process itself works, the end user picks a model from a picklist, runs the commit event thereby resettting each node inside entire hierachy. Our main concern is the possilbe risks involved in running a TI on a control cube, especially a control cube which controls applications web. We would like to know if anyone would reccommend, warn against, or reject this process.

Well all that the TM1 Application Web interface is doing is running a process, to achieve the same. So in theory nothing wrong with this approach as long as you are touching all the right objects and none of the wrong ones! The best thing to do is run it manually, then analyse which }tp process was fired and what it did then write something that users can call that either does the same thing or just calls the }tp process with the correct parameters.

[TrevorGoss]

Well all that the TM1 Application Web interface is doing is running a process, to achieve the same.

Indeed, it fires, I think, two TIs to change the state of the node. Both of them }tp processes. What I did to find out how to change it myself was to follow the two TIs to the control cube. The control cube is:
'}tp_application_state}-uniquieID'

So in theory nothing wrong with this approach as long as you are touching all the right objects and none of the wrong ones!

Agreed, we are worried however about IBMs comment to us, when we asked them a few years ago if they would support this kind of process. They said they would not support it.

[lotsaram]

Agreed, we are worried however about IBMs comment to us, when we asked them a few years ago if they would support this kind of process. They said they would not support it.

To be fair caveat emptor or better periculo tuo is fair enough here and is standard with any software. If you want to hack in behind the scenes then at your own risk is fair enough, just like modifying anything under the hood voids the manufacturers warranty. IBM warrant the functionality of Contributor but no guarantee they won't change some mechanism of how it does stuff between one version and the next, and as far as contributor goes they have done so already, how security is handled is completely different in 10.2 vs. the first release in 9.5.

[tomok]

I would assume that any time you change the behavior of ANY of the control cubes directly, either via rule or TI, you are probably doing something that IBM doesn't "support". A new release of TM1 could render any of those things non-workable going forward. That wouldn't stop me from doing it if there was a valid business purpose for doing it and the payoff in time savings for implementing the change was substantial.

[lotsaram]

Yeah, also what he said.

[TrevorGoss]

Chaps, happy 2015 to you both.

I would assume that any time you change the behavior of ANY of the control cubes directly, either via rule or TI, you are probably doing something that IBM doesn't "support".

Indeed, we did not take it as a no no, but just as a caution.

A new release of TM1 could render any of those things non-workable going forward.

That is always a problem, a fundamental change within TM1 could alter our set up. Fundamental changes only really occur upon new TM1s, such as TM1 9.5 to TM1 10.1.

That wouldn't stop me from doing it if there was a valid business purpose for doing it and the payoff in time savings for implementing the change was substantial.

The change is substantial because it will please our end users to run an event that does somthing in seconds, that use to take ages.

I will keep this post updated with any changes, updates or success stories with this project.

Thanks.