Thursday, 27 March 2014

Patch Delivery System v0.3

A huge update in this release!

The first big difference is that now instead of calling opatch.bat to apply the patches, I actually invoke the Java program directly. This means that the error codes can be checked more reliably and that the program logic actually works correctly now - opatch.bat file did weird things to the script execution! This now means that PDS will detect automatically if a patch did not apply correctly and prompt to re-apply only in case of errors. You can also attempt to re-apply the patch as many times as you want - previously you only got 2 chances!

To facilitate the above change I had to make a lot of changes to the setEnv.bat file and introduce a new file: setEnvOPatch.bat. These 2 files pull in all the environment variables required to run OPatch without going through opatch.bat. setEnv.bat also includes more checking of variables, more error checking and some new routines for detecting the location of the JRE\JDK.

I have also added more error checking in general to all of the scripts and tried to clean up the output of the scripts, to make it look a little better on the screen.

I have now included example configuration files for a machine called "WINKER". This is to help with creating your own config files.

I additionally have also created a README.txt file - so you should be able to figure out what the heck you are supposed to do with this thing a bit easier now!

For the next version I will have to finally go through the scripts and sort out the names of all my GOTOs - they are not very descriptive right now and need to be sorted out. I also should give some more meaningful comments, to make things a little easier to figure out if you wanted to delve into the code.

I am not sure where to take the scripts next after that. It might be nice to have a GUI tool to show the success or failure of each patch operation, creating a nice report of how the patching went or something like that. The problem is that you can't really fully automate EPM and OBIEE patching because they usually require some manual pre and post patching steps, such as copying files, deleting folders or redeploying components to WebLogic.

Please let me know if you use these scripts, have scripts of your own, have ideas on how to improve them or wish to report any bugs.

You can download version 0.3 of PDS here.

Monday, 9 December 2013

Patch Delivery System v0.2

Update: Apologies, the ZIP file was altered by anti-virus software and this is not usable. I will have to update the script after I have come back from my travelling.

Update 2: The fixed ZIP file is now available! I will soon be starting a parallel project to create a very similar script in a proper programming language like Perl, Python, Java, Jython or possibly AutoIt. I believe Perl and Jython are supported out-of-the-box by EPM and OBIEE installations so they may be preferable - although I will have to double-check.

You will have to forgive the lack of posts recently, I have embarked on an adventure and don't always have ready access to a computer!

This is to release the next version of PDS (Patch Delivery System).

This set of Windows batch scripts provide a way of streamlining the process of patching a Hyperion EPM installation. Basically with a little preparation it means you can run one script that will install the patches in the order you require, giving the operator time to read the README file for each patch before continuing to the installation. This removes some of the manual effort from patching the system.

New features for this version include OBIEE support! This is assuming that the BI_ORACLE_HOME variable has been set, and the ORACLE_INSTANCE variable should also be set up. As an aside it is highly recommended to add these 2 environment variables to OBIEE installations whether you are using PDS or not as they resolve some issues.

Also there is some more error-checking and more prompts available to check with the operator if a patch has actually applied successfully or not.

For the next versions I would like to find a reliable way of detecting if a patch has applied successfully or not to remove the need to prompt the user for information - but that would require getting deep into the inner workings of OPatch, unfortunately.

You can download v0.2 of PDS here.

Monday, 21 October 2013

SAML2 SSO for EPM

So the last post was completely devoid of any kind of context as I was really writing it in a rush.

Here I will try to give some more details.

I have been spending some time configuring SAML2 SSO for EPM. SAML2 SSO is basically "seamless" single sign on - "one click and you are logged in". No need to type usernames and passwords.

The first thing you should know is that Oracle's documentation on the subject is sometimes confusing and sometimes wrong. That said the documentation is available here, and you should refer to it for the steps in detail. I will try to be as clear as I can when you need to differ from the documentation.

First of all you should patch your environment to the highest possible. If you are on 11.1.2.1 you need to download this patch to solve a bug with Workspace not logging in correctly with SSO:

17370092

Also you should know that as soon as you configure SSO, Planning will not start. This is due to a bug in Planning. The fix is in the Windows registry, you need to look for the startup parameters for Planning (under HKLM\Software\Hyperion Solutions\HyS9Planning, usually) and delete these parameters if they exist:

-Djavax.xml.parsers.DocumentBuilderFactory
-Djavax.xml.transform.TransformerFactory



In the example above those options have been overwritten with "-Djaxp.debug=0" - which does nothing.

If you do not Planning will crash as soon as SSO is set in the WebLogic domain.

Now a caveat: EAS Console, Essbase Client, Smart View, Essbase Excel Add-In, FDM Workbench, HFM Client and any of the other "thick" software clients do not support single sign-on of any kind. You will still get a login box.



Seamless SSO for Smart View may be coming in a later release, we will have to see on that one.

Firstly you should try to fully configure the authentication source in WebLogic and Shared Services. These will typically be an LDAP directory, they should both be configured in the same way and (under normal circumstances) use the same authentication source as the Federation Services server.

 

It is required in WebLogic as the actual SAML2 SSO is done as a WebLogic operation and as such when WebLogic takes the SAML2 response and tries to map the response to a user it will do so in the internal authentication providers of the WebLogic domain. Then it will pass the user to Foundation Services and it will get logged in automatically.

With the authentication providers set up you need to configure the Identity Provider Partner. There are guides on how to do that elsewhere so I won't cover it here.



The Service Provider configuration can be a little tricky, not least because Oracle doesn't tell you the correct URL to use as the for the Published Site URL. It should be http://server1:19000/saml2/ not
http://server1/.
 


The SSO configuration in Shared Services is quite straightforward, those steps are available in the guide.

The SSO Diagnostic application can be handy for diagnosing issues and should be deployed. The OHS configuration is required and should definitely be completed.

With the CustomRolesAndPolicies step - I think this might only be required if you wish to restrict SSO to only certain users. Even though this was not the case for my configuration I did it regardless.

If all these steps have been done then you should be up and running.

One issue we had is that by default WebLogic maps the Subject of the SAML2 response to the WebLogic user. If the user exists in WebLogic then the username is passed back to Foundaton Services to be logged on. This will probably be a required configuration 75% of the time but we wanted to map a specific attribute in the SAML2 response to a WebLogic user. Unfortunately the only way to do this is by writing a couple of custom Java classes to override the default way WebLogic maps SAML2 responses to WebLogic users. That is what the previous post covered.

I may go over the above steps in more detail some other time. Otherwise good luck on getting SSO in EPM :)