Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Idle a Project During Warehouse Build

Status
Not open for further replies.

angi

Programmer
Apr 14, 2003
9
0
0
US
I am trying to determine how to idle a project during the warehouse build so that users are not able to run reports until the build is completed. Here is our setup:

Server A: MicroStrategy Intelligence Server (incl Metadata)
Server B: MicroStrategy Web Server
Server C: Warehouse SQL Server (contains no MicroStrategy components)

Sometime during the night, Server C gathers data from our mainframe via stored procedures and DTS packages. Given the volume of data, this process usually takes several hours to run. In addition, the exact time that it runs can vary from day to day based on when the mainframe has completed all of the prerequisite jobs.

We have users that access data around the clock; however, I need to idle the project when Server C is gathering the data so that users do not receive incomplete or incorrect data on their reports. I want to minimize the time that the project is down by idling the project when Server C starts its work and resuming the project when Server C completes its work.

The only way that I know of idling and resuming a project is to set up idling and resuming events based on triggers. However, the only way that I can trigger these events automatically is to tell our warehouse build to execute Command Manager scripts. This means that we would need to install MicroStrategy on Server C, our warehouse server, just to get the Command Manager scripts to run. (I tried running these scripts on a machine that doesn't have MicroStrategy components installed, and I simply receive error messages referring to missing components, dll's and the like).

Is there any other way that I can idle a project? Is there some record in the metadata whereby I could just tell the warehouse build to update a column value via SQL to idle a project and then update the same column value at the end of the warehouse build to resume it?

Thanks for your help.
 
I know this might not be the best option but we use a scheduling tool that triggers a batch file to run on the NT server. Another possibility might be if you can write a little program that checks for a file in a certain location periodically and then run command manager when the file gets copied to that location.

 
nope, there's no way to do that. The problem is that such a solution would require the iserver to constantly poll the metadata -- something system admins have recognized is bad...

so what are we mortals to do? I suggest the following

1) obtain the "fireevent.exe" from their tech support.
2)set up schedule S1 that is triggered by event E1.
3) schedule the admin task idle project to S1
4) repeat 2 and 3 for resume project
5) when your db load starts, run the CL function "fireevent -fire "E1" -srv "servername" -prt "0" -uid "userid" -pwd "password"
6) when your dbload ends, run CL command
"fireevent -fire "E2" -srv "servername" -prt "0" -uid "userid" -pwd "password"

good luck
 
I called Support and they told me that fireevent is not supported. Now we are supposed to use CommandManager.

They also mentioned something about RSH (sp?), but my admin group said that they do not allow it.

As I am a big fan of Narrowcast Server, I will try to see if we can get it to do that! :)

HTH,
Flb
 
My solution would be to use a free tool called psexec. It can be found at
The psexec can execute any command on another machine as any user you want. When you kick off the load process you can run the program from Server C with the commmand manager script sitting on Server A.
To idle the project you can do something like

psexec \\servername -u user -p passwd c:\command.

Then do the same thing when the load is finished using your resume command.

The script on Server A can be in any directory on the machine. Just make sure the full path is in the psexec argument for the command. You can also log on to server A as a domain user by doing DOMAIN\user for -u parameter.

I have used this tool in many scenerios in MicroStrategy and it works great. It doesn't use the rsh service so you should be safe.
 
Hi all!

We currently phase the same problem - but in a different configuration.

Our ETL part resides on a Unix box within an Oracle database.

Has anyone ever implemented a "trigger event" function from Unix? Maybe even out of Oracle?

I do see two possible ways to go:

1) Use the MSTR SDK on Unix
Is it possible to install the MSTR SDK on Unix and adapt the "FireEvent" sample code (replacing the registry calls by another config method) - or is the SDK specificly bound to Windows?

2) Generate an RPC call from Unix to the Windows Box running the Intelligence Server and execute the command manager as described above.

Any experiences, thoughts?
 
Another way to do this would be -

On the start of the load of the warehouse - copy a .bat file from a UNIX directory to a UNIX/NT share (we use a piece of software called SAMBA to create this share)
Then using NT schedules on the MSTR Intelligence Server this .bat is run (we poll the shared directory every 5 mins) and the IServer could be idled.

The .bat file should contain a command manager cmd which in turn uses a script file located on the NT server - to idle the IServer.

At the end of the .bat file a cmd should delete the .bat file from the shared directory - so that it doesn't get run again and again every 5 mins.

This solution shouldn't breach the security of your platfrom

This could be repeated with another .bat file (and another script) - to restart the server

Hope this makes sense and helps a bit
 
We can not use Microsoft Shares in our production environment (security concerns), so Samba is not even a remote option.
Instead we implemented a solution based on sftp and OpenSSH (free! :) ) that allow us to move files around. The only problem we have at this time is the necessity to hardcode usernames and password in our connection scripts.... We were able to get a security exception accepted but we have only one year to get this resolved.... I hope MicroStrategy will start supporting their API in the Unix world sometimes in the next year....
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top