Oracle Critical Patch Update Q1, 2015 – OBIEE 11.1.1.7.150120

Oracle’s quarterly Critical Patch Update came out today (1/20/2015). While the Hyperion products did not have any critical patches come out in the last quarter from a security perspective, the OBIEE products were included. Taking a look at the document, OBIEE and BI Publisher are listed as requiring a recommended security patch (number 20124371).

The OBIEE 11.1.1.7.150120 comments on the My Oracle Support Document 1488475.1 state that this will likely be the last bundle patch for the 11.1.1.7 version.

Per the readme:

The Oracle BI EE Suite Bundle Patch 11.1.1.7.150120 under the top-level patch 20124371 consists of the following component patches:

Patch Abstract

16913445 Oracle Business Intelligence Installer (BIINST)

19822893 Oracle Business Intelligence Publisher (BIP)

19825503 Enterprise Performance Management Components Installed from BI Installer 11.1.1.7.0 (BIFNDNEPM)

19822857 Oracle Business Intelligence Server (BISERVER)

19822826 Oracle Business Intelligence Presentation Services (BIPS)

19823874 Oracle Real-Time Decisions (RTD)

16997936 Oracle Business Intelligence ADF Components (BIADFCOMPS)

20022695 Oracle Business Intelligence Platform Client Installers and MapViewer

Patch	Abstract
16913445	Oracle Business Intelligence Installer (BIINST)
19822893	Oracle Business Intelligence Publisher (BIP)
19825503	Enterprise Performance Management Components Installed from BI Installer 11.1.1.7.0 (BIFNDNEPM)
19822857	Oracle Business Intelligence Server (BISERVER)
19822826	Oracle Business Intelligence Presentation Services (BIPS)
19823874	Oracle Real-Time Decisions (RTD)
16997936	Oracle Business Intelligence ADF Components (BIADFCOMPS)
20022695	Oracle Business Intelligence Platform Client Installers and MapViewer

This release has no new features; however, there are 130+ new bug fixes in this bundle patch.

In addition to this patch, the Dynamic Monitoring Service Patch (number 16569379) and Patch 18277370 for running Enterprise Manager in IE11 are also required. If it’s a new install or you haven’t updated your BI Mobile Application Designer, it would be a good time to install patch number 18794832 as well.

*** EDIT 1/23/2015 – after multiple people found the note in Oracle KB Article 1488475.1, the note was removed from the document. Oracle reserves the right to patch if necessary; however, I have a feeling development is going to be more focused on the 12c version of OBIEE.

Fixing errors in Calc Manager 11.1.2.3.502 Custom Defined Functions

**** Please see the edit at the bottom of this post for important information ****

Celvin Kattookaran and Cameron Lackpour have previously blogged about the Calc Manager 11.1.2.3.502 CDFs. Celvin does a great job in both the ODTUG Blog “Tech Tips” article and his blog where he describes the use of some of these functions. As I was researching these functions, I found several errors in my Essbase application logs where five of these functions are not registered properly.

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.exportData(String,String,String,String,String,String,String,String,String,String,String,String,String,String,String)] (function [@CalcMgrMDXExport]): [specified class not found:com.hyperion.calcmgr.common.cdf]

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.StringFunctions.substring2(String,int,int)] (function [@CalcMgrSubstring]): [specified method not found:com.hyperion.calcmgr.common.cdf.StringFunctions::substring2(java.lang.String,int,int)]

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.StringFunctions.indexOf(String,int)] (function [@CalcMgrIndexOf]): [specified method not found:com.hyperion.calcmgr.common.cdf.StringFunctions::indexOf(java.lang.String,int)]

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.StringFunctions.lastIndexOf(String,int)] (function [@CalcMgrLastIndexOf]): [specified method not found:com.hyperion.calcmgr.common.cdf.StringFunctions::lastIndexOf(java.lang.String,int)]

[Wed Jan 07 11:46:43 2015]Local/Vis_ASO///13072/Warning(1200490)
Wrong java method specification [com.hyperion.calcmgr.common.cdf.CalendarFunctions.getCurrentDate(int)] (function [@CalcMgrGetCurrentDate]): [specified method not found:com.hyperion.calcmgr.common.cdf.CalendarFunctions::getCurrentDate(int)]

@CalcMgrGetCurrentDate

So, how do we fix these? Celvin comes to the rescue on the first one. In his Tech Tips article, he explains that we need to remove the “int” input parameter in the Java Method field.

In EAS, I right-clicked on my Essbase server and selected Edit>Functions.
Inside the CDF Manager, I selected the @CalcMgrGetCurrentDate function and clicked the Edit button.
Inside the Edit Function window, we change the Java Method field from getCurrentDate(int) to getCurrentDate().
Stop/Restart an application and view the log to verify that the function is registered properly.

That works great and it’s one down, four to go.

Change getCurrentDate(int) to getCurrentDate()

@CalcMgrIndexOf and @CalcMgrLastIndexOf

Next we can fix @CalcMgrIndexOf and @CalcMgrLastIndexOf with the same steps. These functions are not declared properly. I took at peek into the Java class for these functions and found that they need to receive two String variables and a numeric variable. The default specification is one String and one number. To fix these two functions, we need to add an additional String to the input parameters in the Java Method field. Change indexOf(String,int) to indexOf(String,String,int). Next we need to edit the Spec field to add “searchString”. Change @CalcMgrIndexOf(text, beginIndex) to @CalcMgrIndexOf(text, searchString, beginIndex).

Change indexOf(String,int) to indexOf(String,String,int) and @CalcMgrIndexOf(text, beginIndex) to @CalcMgrIndexOf(text, searchString, beginIndex)

@CalcMgrSusbtring

With the @CalcMgrSusbtring function, we need to edit the Java Method and Spec fields to remove the “2”. Change substring2(String,int,int) to substring(String,int,int), then change @CalcMgrSubstring2(text, startIndex, endIndex) to @CalcMgrSubstring(text, startIndex, endIndex). If you use EAS to edit this function, you will run into an error when trying to save the change back. The error looks something like this:

The Comment field is over 256 characters.

Great, now what? Well, we can edit the comment field and remove the third line and that would allow us to save the function back since we would have reduced the comment field to under 256 characters. More on that later… Until then, this is what your function should look like when it’s fixed.

Fixed @CalcMgrSubstring function definition.

@CalcMgrMDXExport

The final function is @CalcMgrMDXExport. Celvin has a great explanation of how this works and shows a great example on this blog, so read that to see how cool this is. This function is missing the Class in its Java Class field. To fix this one add “.MDXExport”. We need to change com.hyperion.calcmgr.common.cdf to com.hyperion.calcmgr.common.cdf.MDXExport.

That’s pretty simple, but we are again going to run into issues with EAS CDF Manager. As we previously found out, the Comment field has a limit of 256 characters in EAS. If you cut down the comment on this function, you’ll also find out that the Spec field has a limit and of course this function is too large. Through testing, I found the limit of the Spec field is 128 characters. The default Spec for this function is 162 characters. We could use shorthand changing “application” to “app” and “database” to “db”, but that’s really a pain. If only there was a way to edit these functions without losing the comments and extended specification.

Essfunc.xml

This is where Cameron’s blog comes in. Cameron has covered the Planning CDF functions in the past and explained that the “essfunc.xml” holds a better explanation of the @Hsp* Planning functions. Well, that’s also the file that EAS looks at when you Open the CDF Manager, only in a different location. So, if you make these same changes to the function specification in the proper essfunc.xml file, the functions will be fixed in EAS and you can then call them like a calculator function.

The essfunc.xml that contains the definitions of my server-wide CDFs, that is the functions that are valid for all applications, is stored in C:\Oracle\Middleware\user_projects\epmsystem1\EssbaseServer\essbaseserver1\java. As I have previously blogged, I prefer TextPad for my text editing duties, so that is the tool I used for editing.

In my copy of essfunc.xml, on line 82 the function for @CalcMgrMDXExport starts:

<function name=”@CalcMgrMDXExport” tssec=”1420730410″ tsmcs=”606000″ javaSpec=”com.hyperion.calcmgr.common.cdf.exportData(String,String,String,String,String,String,String,String,String,String,String,String,String,String,String)”>

To fix this one, all we need to do is edit that one line to:

<function name=”@CalcMgrMDXExport” tssec=”1420730410″ tsmcs=”606000″ javaSpec=”com.hyperion.calcmgr.common.cdf.MDXExport.exportData(String,String,String,String,String,String,String,String,String,String,String,String,String,String,String)”>

Just inserting “.MDXExport” in the javaSpec is all we need to do. No messing around with shorting the Comment or Spec fields needed. Save the file back to the server. To verify the change was made, we can view the function in the EAS CDF Manager where we should see our edits have saved properly. Stop and restart your application to verify that the edits were successful and that the function has registered properly.

The five specification errors fixed and ready to be used.

****EDIT 6/11/2015 **** Calculation Manager 11.1.2.3.505 fixes these errors, so just apply PSU 20968612 and you won’t need to mess with fixing the CDF registration in EAS or the essfunc.xml.

2014 in review

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog. Even though I am a little late, I wanted to share a quick year in review.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 15,000 times in 2014. If it were a concert at Sydney Opera House, it would take about 6 sold-out performances for that many people to see it.

Just before Thanksgiving, I received an email from Oracle notifying me that I had been accepted into the ACE program as an Oracle ACE Associate. Thank you to Steve, my friend and past client for the nomination and thank you to Oracle for the recognition. I would not be in this position without my wife, Lindsey, who drastically changed her career so that I could pursue mine. Being an ACE Associate will help me to continue helping others learn and grow in their careers. Thank you again to Oracle and Steve!

I also received notice that one of my abstracts has been selected for presentation at ODTUG KScope15 in Hollywood, Florida. I always look forward to KScope for the learning opportunities and the chance to see friends that I don’t get to see any other time during the year. This will be my seventh KScope and it’s amazing to see how it has grown from the “one-room conference” in 2008 to today.

2014 was an amazing year and I’m looking forward to a busy 2015! Happy belated new year, everyone.

FDMEE 11.1.2.3.520 connections – ODI trickery for Oracle databases

I recently wrapped up an infrastructure project at a client that needed to prove the connection between Peoplesoft and FDMEE would work. The client will then use this connection going forward as he builds out his brand new implementation.

We kept getting stuck with the FDMEE connection “initialize” step. The DBA granted us read-only access to the Peoplesoft tables through a separate schema than the owner of the tables. For security reasons, they didn’t want us logging directly into the Oracle database as the owner of the Peoplesoft tables and for that I cannot blame them. I setup the connection in ODI as I have a few times before and expected that everything would be just fine. Unfortunately, we kept getting an Oracle error in ODI: ORA-00942: table or view does not exist.

I connected to the schema using SQL Developer and when I tried to view the tables, I could see that no tables existed under my service account schema. I was able to query the Peoplesoft tables through synonyms, though, so we assumed that everything would work fine.

As we looked at the errors in the ODI logs, we could see that it was attempting to access the tables using a “Schema.Table” naming convention. The schema that it was using was our service account schema “SVC_HYPERIONSQL”. Since that schema didn’t contain any tables, it was clear that was the cause behind the errors, but how to get the integration to point to the correct schema where the tables exist?

I went back into ODI and looked at the Data Server connection. That’s when I realized that the “Schema” that it was asking for needed to be the owner of the Peoplesoft tables. We could use our other service account schema as the Work Schema, but in order for the integrations to run properly, they needed to access the tables using the correct account, which was SYSADM for this environment.

Must select the proper schema that owns the ERP tables when using Oracle repositories.

After selecting the proper schema, the “Initialize” step in FDMEE worked without a hitch.

Essbase, EAS, APS, and Essbase Studio 11.1.2.3.505

Last Tuesday, Oracle released new patches for Essbase and friends (EAS, APS, and Essbase Studio). The Patch Set Update brings the new version to 11.1.2.3.505. Here are the relevant patch numbers for your reference:

Product:	Patch Number:
EAS Server	19613844
EAS Console MSI	19613853
APS	19509172
Essbase Studio Server	19509186
Essbase Studio Console MSI	19509181
Essbase Server	19906085
Essbase Runtime Client	19906081
Essbase Client	19906103
Essbase Client MSI	19906079

I think that it’s great that we now have Oracle Essbase, APS, EAS, and Studio all on the same patch versions again. The readme files actually state, “Oracle recommends using the same version of all Essbase portfolio products (Essbase, Essbase Administration Services, Hyperion Provider Services, and Essbase Studio) and components (server, client, runtime client, API, and JAPI).” Given that, if you want one of these patches, you should install them all.

The majority of the content in these patches are various bug fixes that are covered in the readmes for each patch. The Essbase server patch appears to focus on performance optimization and stabilization; however, there a couple of noteworthy items in that readme.

There was a new calculator command added with Essbase 11.1.2.3.500 that was not documented. It is SET CALCDIAGNOSTICS. This command enables diagnostic logging for CALCPARALLEL and FIXPARALLEL commands. This logging is not on by default, since there is some performance overhead. This feature is designed to help in tuning parallel operations, then it should be turned off.

Here are the example from the Essbase 11.1.2.3.505 readme:

Examples

The following example enables diagnostic logging for all parallel calculations in the calculation script.

SET CALCDIAGNOSTICS { LOGSIZE 4; };

FIXPARALLEL (2, @IDESCENDANT(“US_Market”))

AGG (“Product”);

ENDFIXPARALLEL

The following example enables diagnostic logging for a specific FIXPARALLEL block.

FIXPARALLEL (2, @IDESCENDANT(“US_Market”))

SET CALCDIAGNOSTICS { LOGSIZE 4; };

AGG (“Product”);

ENDFIXPARALLEL

Sample Diagnostic Log Output for FIXPARALLEL

The following sample output pertains to FIXPARALLEL parallel calculation.

OK/INFO – 1012899 – Statistics for [Calc1.csc], FIXPARALLEL of index [1] at line [14]: Number of FIXPARALLEL Threads = [2], Total Tasks = [261], Min/Max/Avg Thread’s Time = [103.453]/[103.519]/[103.486] secs.

OK/INFO – 1012899 – For [4] Longest tasks, next rows display : Time(secs), Thread_id, (Task_index/Task_count), Task_id, Member-combinations.

OK/INFO – 1012899 – 15.131, 1, (30/132), 53, [ID_051341].

OK/INFO – 1012899 – 10.759, 2, (124/129), 211, [ID_050092].

OK/INFO – 1012899 – 9.690, 1, (42/132), 125, [ID_052230].

OK/INFO – 1012899 – 7.192, 1, (38/132), 105, [ID_052073].

OK/INFO – 1012899 – Summary for thread[1]: Total Time = [103.519] secs, Total Tasks = [132].

OK/INFO – 1012899 – Longest tasks executing on thread[1] : Time(secs), Thread_id, (Task_index/Task_count), Task_id.

OK/INFO – 1012899 – 15.131, 1, (30/132), 53.

OK/INFO – 1012899 – 7.192, 1, (38/132), 105.

OK/INFO – 1012899 – 9.690, 1, (42/132), 125.

OK/INFO – 1012899 – Summary for thread[2]: Total Time = [103.453] secs, Total Tasks = [129].

OK/INFO – 1012899 – Longest tasks executing on thread[2] : Time(secs), Thread_id, (Task_index/Task_count), Task_id.

OK/INFO – 1012899 – 10.759, 2, (124/129), 211.

The diagnostic output is organized into 3 sections.

Under the known issues section, I did see this interesting tidbit:

To avoid abnormal application shutdowns,

o Do not use the DELAYEDRECOVERY configuration setting in essbase.cfg, and in particular, do not set it to FALSE

o Do not run the MaxL statement alter database recover freespace.

There are a few other documentation updates listed at the bottom of the Essbase readme, mostly clarifications on a few points from previous readmes.

New EPM Patches for 11.1.2.3

Since my last post, Oracle has released a number of new patches. I wanted to take a moment to summarize them quickly and give the links. The Oracle Proactive Support Team (PST) for EPM and BI (@Oracle_EPMBI on Twitter) has been doing an excellent job of publishing these patches lately. I started this blog nearly three years ago and it had evolved into a patch notification site. I am looking forward to blogging about more interesting topics now that Oracle is taking over notifying the public on new patches.

The following products have new patches released in the last week or so:

Shared Services 11.1.2.3.502
Smart View 11.1.2.5.216
EPM Architect (EPMA) 11.1.2.3.501
Hyperion Strategic Finance (HSF) 11.1.2.3.504
Financial Reporting (FR) 11.1.2.3.505

Shared Services 11.1.2.3.502 (patch 19447055)

This patch came out on 11/4 and contains seven bug fixes, primarily fixing issues with HFM provisioning/access control issues and a new Planning LCM dimension merge/replace option.

Smart View 11.1.2.5.216 (patch 19858481)

The newest Smart View patch was released on 11/5 and contains fixes only for OBIEE. If you are in an EPM-only environment and do not have OBIEE, I would recommend just staying on the 11.1.2.5.210 patch which is still the latest version on the Oracle Technology Network (OTN) download page for Smart View. This patch fixes performance issues when using OBIEE as a data source and requires two prerequisite patches to be applied to OBIEE (18507268 and 18828701).

EPMA 11.1.2.3.501 (patch 19466859)

EPMA 11.1.2.3.501 was released on 11/14. There are seven defects fixed with this patch to make metadata management better with EPMA applications. If you are using EPMA, this is one you should apply.

HSF 11.1.2.3.504 (patch 19689889)

This patch was released on 11/11, there are four bugs fixed in this release.

Financial Reporting 11.1.2.3.505 (patch 19795686)

Released on 11/14, this patch contains 19 defects fixed and is recommended for all deployments on 11.1.2.3+.

As with any patches, please review the readme files for installation and known issues. In some cases, known issues can be mitigated with the information contained in the readme files.

SSL woes

There I was, trying to wrap up a client’s installation but I was stuck. This particular client has security concerns, they even have an external security company verify their installations and enforce corporate security policy. That meant that OBIEE and EPM needed to both be secured by SSL.

I went down a rabbit hole to get SSL installed in OBIEE, that was an adventure in itself and it took me quite awhile to make sure everything was working properly. I found a great resource from Oracle on their blogs page here: https://blogs.oracle.com/pa/resource/Configuring_OBIEE_with_Ful_End_to_End_SSL.pdf. Thank you to Veera Raghavendra Rao Koka for the detailed information. I wish it was documented similarly in the BI documentation.

For awhile, I wasn’t concerned with EPM SSL. I had implemented SSL termination at Oracle HTTP Server before in version 11.1.2.1, so I figured it would be pretty easy on 11.1.2.3.500+. Wrong. According to the documentation, there are only two supported scenarios for SSL deployment:

SSL Termination at an SSL Offloader (load balancer or bridge with SSL termination enabled)

Full SSL deployment

Hmm. I don’t want either one of these options. My client doesn’t really want un-encrypted traffic from their SSL bridge in their DMZ to the server inside the firewall. So, I started to go down the path of full SSL. This is a distributed installation, so that requires two different keystores for my servers running WebLogic JVMs, plus another keystore for Oracle HTTP Server. I worked at it for awhile and was able to get the Foundation server deployed with full SSL. I started the services and things appeared to be ok. I was able to get into Workspace and click around into Shared Services fine. I went into Calc Manager and the application appeared to be ok, but I got an error about not being able to connect to EPMA. I tried to go into the Dimension Library, then I saw an error message:

Nested exception is: HTTP transport error:javax.xml.soap.SOAPException: javax.xml.soap.SOAPException: Message send failed: Unrecognized SSL message, plaintext connection?

At this point, I had pretty much had enough. Oracle Support’s Knowledge Base article 1904344.1 states that this is a known issue that should be fixed with Shared Services patch 11.1.2.3.501. Unfortunately, I had already applied that patch during the installation and I was still seeing the error. Ain’t nobody got time for that.

So, I really didn’t want to pursue full SSL at this point. What I really wanted was to do what I had done back in 11.1.2.1 and accept SSL connections at the Oracle HTTP Server layer and terminate those SSL requests there. That would preclude me from needing to mess with keystores at the WebLogic layer and avoid any issues with EPMA in SSL mode. This is what I’m talking about:

The 11.1.2.3 Security guide mentions terminating SSL at the HTTP server; however, the architecture diagram they provide is the same diagram as SSL termination at an offloader. The above diagram is actually from the 11.1.2.1 documentation and exactly what I want. So, I did some Google magic and found that Pablo Bryan of Infratects has a blog and documented the exact steps that I needed back in January of 2014. You can read his blog post here: http://hyperionvirtuoso.blogspot.com/2014/01/you-have-many-options-to-secure-your_14.html. Thank you, Pablo!

So, I took his advice and made the two or three changes to the ssl.conf and httpd.conf files. After restarting Oracle HTTP Server, all was right with the world and my client now has encrypted communication terminating at the HTTP Server. It really is amazing how easy it was to set up the EPM encryption at the HTTP Server compared to the full SSL required by OBIEE.

I am humbled, thank you.

Last week on Thursday, this blog achieved a milestone. Until then, the highest number of views was 114 in a day which was set last October. That 114-view number stood for an entire year until it was broken last Thursday by 142 views. Also on Thursday, this blog went over 20,000 views all-time.

Yesterday, that 142 number was eclipsed by 165 views. We broke the record again, two business days after smashing a year-long record.

Granted, these are not huge numbers, but for a niche technology blog it feels pretty amazing that there are that many people out there wanting to get some information that many of us may take for granted. I am humbled that so many have come here for information and I thank you for reading.

Quick Followup on Essbase 11.1.2.3.504 and Calc Manager 11.1.2.3.502

On Friday, I mentioned that the patches for Essbase Server and Run-time Client 11.1.2.3.504 used the same OPatch numbers as the Essbase Server and RTC 11.1.2.3.503 patches, respectively. I wasn’t sure if we would need to roll back those .503 patches in order to apply the .504 patch. The answer is no, there is no need to roll back the existing .503 patch. As I ran the .504 patches, the OPatch process did an auto-rollback of the old patch and then applied the later version of the patch. So that was easy.

This morning, I saw that Oracle released Calc Manager 11.1.2.3.502. There’s 7 bug fixes in this patch, and they all seem to be refinements to the product. I did note in the readme that you should apply this Calc Manager patch to any server running the following:

Calculation Manager
Hyperion Planning
“Oracle Hyperion Financial Data Quality Management ERP Integrations Adapter for Oracle Applications (ERP Integrator)” (I’m sure they mean FDMEE here)
EAS
Essbase Server

So, this Calc Manager patch has the potential to be applied to every server in a distributed installation, depending on how you spread your products out.

Essbase 11.1.2.3.504

There is a flurry of activity going on with the Essbase product development team at Oracle. Glenn Schwartzberg had the scoop on Essbase 11.1.2.3.504 that released just a few hours ago.

As I look at the current readme, I am struck by two things:

This entry: “Caution: Oracle recommends using the same version of all Essbase portfolio products (Essbase, Essbase Administration Services, Hyperion Provider Services, and Essbase Studio) and components (server, client, runtime client, API, and JAPI). When only some Essbase portfolio products are included in a patch release, the last released versions of the products that are not included in the patch are supported.Essbase Administration Services 11.1.2.3.503, Provider Services 11.1.2.3.502, and Essbase Studio 11.1.2.3.502 are supported for use with Essbase 11.1.2.3.504.”
And then this under Known Issues in this Patch: “The opatch ids for this patch were not updated so after unzipping the opatch file the root directory will not match the opatch id from 11.1.2.3.504 but will be the opatch ids from 11.1.2.3.503. Any warnings from opatch can be ignored.” I am wondering if you have applied the .503 Essbase patch, you may need to rollback that patch in order to apply the .504 patch since the IDs are the same. I can report back on that later since I have .503 installed at a client site and now need to update it.

There are a set of patch numbers that you can search for, or just search under the Hyperion Essbase product. There is no Essbase client MSI on Oracle Support for Windows (yet). As per #1 above, the client for 11.1.2.3.502 should be fine as it was against Essbase 11.1.2.3.503.

Component	Patch ID
Essbase Client MSI (Windows)	19613877
Essbase Client (OPatch)	19613886
Runtime Client	19613868
Essbase Server	19613865

The list of defects fixed isn’t terribly long; however, it appears that this patch addresses some instances where the Essbase server and/or applications may stop responding or terminate. Based on that alone, it’s probably a good idea to patch any .500, .501, .502, or .503 instances to .504.

The EPM Garage

Tuning Enterprise Performance since 2006