TM1 Forum

All,

Had an interesting one appear today.

Run a TI Process via an action button in tm1 web on "service a" that runs in bulk load mode.
For the duration that this process is running users are unable to log onto this service through TM1 Web or any other method (as expected.)


What I have also found though is that users are not able to log onto other services ("service b") using the same web server.


I wasn't aware that bulk load mode would interfere with other services on the box and I believe the users are still able to interact if they went in via perspectives to other services, the operations console shows the other service as not being in Bulk Load Mode.

Can anyone else confirm if this is "expected behavior" and documented perfectly well and I'm just to blind to see - or a known bug?
If not could anyone else do a quick test and see if they can replicate it?

I'm using TM1 10.1.1, Integrated Logon Mode - 2.


I will also do my own test using Logon Mode 1 to see if its anything to do with that.

Cheers,
Declan

We've hit issues with Bulk load in the past but not this one. I've only ever tried implementing it on single service server. I would however say that due to other problems that we had with bulk load we have taken the approach of removing all security access for users before starting the load instead of using bulk load. Try this instead, hopefully you won't get the same result,

Jim.

jim wood wrote:we have taken the approach of removing all security access for users

That was exactly my backup plan.
All security is rule defined anyway and part of the process (copying versions) destroys all my rules for cubes with the version dim and adds them back in later so I may just add security cube rules into the mix.

Bulk Load Mode seemed so promising so I'm quite disappointed.

I share that disappointment. If you do a search you'll find plenty of posts on bulk load including the ones from me when we were trying to introduce it. I think other people have go it working saying that so somebody else may reply with a positive point of view. You never know.

To be fair it has been working perfectly well in the scenario I introduced it to with the exception of killing tm1web for all services.

Had I just been using a single service web server it would have been perfect... but life is never that easy. And of course this issue only became apparent 2 days before go-live

declanr wrote: What I have also found though is that users are not able to log onto other services ("service b") using the same web server.
(...)
Can anyone else confirm if this is "expected behavior" and documented perfectly well and I'm just to blind to see - or a known bug?

I think this could be treated as expected behavior as per functionality mentioned by tm1_bloke in this post.

If both "service a" and "service b" TM1 servers have the same client account (and password? - not sure, never tested), while logging into "service b" TM1Web will also be logging in to "service a" (and any other "services" running on the same Admin Host).

The only hint I found in documentation is here suggesting to register those services under different Admin Hosts (hmmm... I would rather opt for parameter in web configuration file to decide if I want to use "multi-database support").

You could play around with "what if I have the same client, but different passwords on servers" but this is probably not something you would consider as a satisfying solution even if you could login to "service b" with no issues.

jstrygner wrote:

declanr wrote: What I have also found though is that users are not able to log onto other services ("service b") using the same web server.
(...)
Can anyone else confirm if this is "expected behavior" and documented perfectly well and I'm just to blind to see - or a known bug?

I think this could be treated as expected behavior as per functionality mentioned by tm1_bloke in this post.

If both "service a" and "service b" TM1 servers have the same client account (and password? - not sure, never tested), while logging into "service b" TM1Web will also be logging in to "service a" (and any other "services" running on the same Admin Host).

The only hint I found in documentation is here suggesting to register those services under different Admin Hosts (hmmm... I would rather opt for parameter in web configuration file to decide if I want to use "multi-database support").

You could play around with "what if I have the same client, but different passwords on servers" but this is probably not something you would consider as a satisfying solution even if you could login to "service b" with no issues.

Same thought crossed my mind as I remembered reading that post but the first user to report it had no logon setup for the service in which bulk load was enabled.

Think in this case just going through the step of removing user access when the TI chain initiates is my best option.

I think bulk load goes in to the same category as replication: good if can get it work as expected otherwise a pain.