2 Replies Latest reply on Jun 22, 2012 8:47 AM by 783124

    Making event scripts generic between environments

      At present we have a couple of FDM event scripts which construct some MaxL statements and then execute them against the Essbase database (to clear data before loading). The problem we have is that the MaxL scripts require hard-coded usernames, passwords and servernames (to log in to ESSMSH). When migrating the scripts between environments, these scripts will have to be manually updated each time for the given environment to which they are being migrated.

      Is there a more elegant solution to this? One idea would be to have the values stored in a single plain text file (in a password-protected share) which would then be accessible by any of the various scripts in a given environment. But I would be interested to learn if there are alternatives to this.
        • 1. Re: Making event scripts generic between environments
          If you migrate environments, you are going to have to do some configuration pretty much anyway you go about it. The question is what is the easiest/most straight foward so that it doesn't get missed during a migration, IMHO.

          I would go with a well defined/documented "Global" config file that contains all of the information that may change. At a minimum, Usernames and passwords should be obfuscated/encrypted; however, it would be just as easy to do the whole file. Realize, that the decryption routines would be in your script code so this isn't 100% secure; however, it would prevent the casual user from quickly seeing usernames / passwords, etc. Furthermore, if you encrypted the whole file, they may not even realize there is a username/password in the file, etc.

          In my mind this is the way to go...

          Some other thoughts though, depending on what exactly you want to do....

          Option 2
          Username / Password / Server could be some variation on the server name so that the script always knows how to generate them. The negative side is that you would always need to create a new user / password anytime server changes, so you are still not escaping manual labor. (Though maybe you could use an API call to create it, but then you probably need a username/password to create the user... AAaaaahhhhhhhhh)

          While neat, this seems like it would suffer from James Bond syndrome. I'm going to kill you now Mr. Bond, but first I'm going to tell you all my intricate plans for world domination, put you in some ridiculous trap with an semi-obvious flaw, AND leave so that you have time to work on your escape......

          Option 3
          Make a Web Service and then have your scripts make a Web Call (i.e. http://www.mycompany.com/GetConfigInfo.asp?secretcode=12341234123) which would return all the info you need. (username, password, servers, etc). AS LONG AS the webservice machine doesn't move around, this might be a decent way of doing it. Anyone sniffing around the local machines would find the config info; however, anyone looking at the scripts would see the call and could just open it in a web browser. You could of course secure that by looking at the source of the request and if it's not an approved server, not return the requested info; however, now you are getting into more maintenance work........

          The time spent making this and potentially maintaining it probably isn't worth it.
          1 person found this helpful
          • 2. Re: Making event scripts generic between environments
            Thanks beyerch2, its really helpful to hear some other ideas and suggestions :-) I think at present I'll be going with option 1, but options 3 sounds interesting for a bigger future project! :-) Thanks for your feedback.