API and .NET - Developer Tools & APIs(Archived)

Hi - Where can I find documentation on the Essbase API and .NET/C#? I've done some API work before with C++, but it looks like that will now be .NET-ified.I assume it is possible to access Essbase via .NET/C#?Thanks! 

Don't bet on it - in fact, it looks to me that it will be Java-fied. Unless Hyperion has released information that they will support the .NET platform, you may be stuck using the older-style C and VB APIs. Hyperion has invested a lot of time and effort getting all their products to support the J2EE standard.However, since .NET will become the defacto Win32 development environment, it would make sense for them to update their APIs to the .NET standard.Regards,Jade----------------------------------Jade ColeSenior Business Intelligence ConsultantClarity Systemsjcole#claritysystems.comwww.claritysystems.com 

I suspect Essbase will live on as unmanaged C. They never took the time to release good COM objects so I would be surprised if they went and wrapped the API just for C#. 

I guess it would be nice if they were to create COM API objects (certainly possible), because that would blend right in with existing COM developers as well as the new force of .NET developers... I supposed as well that I could do that myself (create COM objects and interfaces and then use them in my C# programs) but... looks like I'll be doing the development in Visual C++ and leaving it there - for now... fortunately/unfortunately, Microsoft is here to stay. 

It is not correct that Essbase has been Java'fied. It is true that we try to stay away from proprietory technologies and therefore we have not spent a lot of effort on C# etc. But we are working with Microsoft on XML For Analysis, which is a web services standard. Hopefully we will be able to expose it in a manner that will allow both SUN ONE and .NET programmers equal flexibility in developing applications. Please visit http://www.xmla.org/ for more details. Hemanta BanerjeeProduct Manager - XMLA & Web ServicesHyperion 

By the way, since this thread began I've managed to create a COM class exposing the Essbase API functions I want in ATL without too much pain - and then use that in my C#/.NET compiler... so - with only a slight bit of additional effort, the Essbase API is now available to me via C# and .NET - so the fact that Hyperion only exposes C (and VB) API's is in no way an insurmountable obstacle... and I'm rather looking forward to continuing this development. 

<p>Hi, can you describe how did you achieve the Essbase APIconnectivity with ASP.NET?</p><p>Thanks in advance</p><p> </p><p>Anand</p> 

<BR>I think the users above wrapped the unmanaged C API files (which basically removes most of the benefits of using .NET in the first place)..<BR><BR>You can use the Hyperion Objects product (now called HAB.Net) which has classes that allow you to work with Essbase via web services.<BR><BR>Tim


.Net support in Essbase API

1) I want to use Essbase API in VB.Net language. Can I use existing VB API in VB.Net ? What kind of issues will I face if I use VB API in .Net ? Or What are the points that I should take care of before using VB API into VB.NET Application ?
2) Does Essbase has set of API in .NET which supports .NET environment/run time ?
Thanks a lot ! 
Depending on what version you are running you could have a look at "Hyperion Application Builder for .NET"
Documentation available at :- http://download.oracle.com/docs/cd/E12825_01/nav/portal_3.htm
The VB API would need to be wrapped with P/Invoke for use in .Net. You may find it cleaner to actually wrap the C API for .Net. Also, as John mentioned, HAB.Net is a viable solution for certain versions of Essbase. A third alternative that may prove even more satisfactory is the Dodeca product at [Applied OLAP|http://appliedolap.com] 
The only times I have heard of someone trying to wrap the VB or C APIs, they were contacting me to ask about the severe performance issues they were seeing (due most likely to the managed/unmanaged call marshalling happening under the covers with every call).
HAB.Net is compiled with .NET version 1.1.
We wrote the HAB.Net API layer, have source code license rights and support it now in our Dodeca product. It is now compiled with .NET 2.0 compatibility and supported on every version of Essbase from 6.5.3 to
Tim Tow
Applied OLAP, Inc 
Thanks a lot John, Tim Tow, Dwelden.
I have gone through the help of HAB for .Net. What I understood is Essbase has provided certain ready-to-use controls and certain base classes that encapsulate the Essbase API. These can be used to connect to Essbase and perform operations on Essbase.
At one place I have seen a control is connecting to Essbase server using some webbased settings/configuration. Is it that we can connect to web based Essbase server only using this control ? or we can connect to a standalone Essbase server running on Windows environment using this control ?
I wish to use Essbser server verion 11.1.x and 9.3.x. Where can I get HAB assemblies.
Many Thanks. 
At one place I have seen a control is connecting to Essbase server using some webbased settings/configuration. Is it that we can connect to web based Essbase server only using this control ? or we can connect to a standalone Essbase server running on Windows environment using this control ?
I wish to use Essbser server verion 11.1.x and 9.3.x. Where can I get HAB assemblies.Using HAB.Net, you must connect to an APS server to talk to Essbase. The HAB assemblies create web-service requests that talk to the HAB service which, in turn, talks to Essbase via the Java API.
Tim Tow
Applied OLAP, Inc 
My team at work has been able to figure out (we think) how to connect through the VB API in VB.NET. Our inplementation is a VSTO addin for Excel 2010.... but still need to do more testing. Then we will probably work on packaging it into a single API interface DLL. Still wonder why Hyperion/Oracle wouldn't/couldn't do it. 
839709 wrote:
My team at work has been able to figure out (we think) how to connect through the VB API in VB.NET. Our inplementation is a VSTO addin for Excel 2010.... but still need to do more testing. Then we will probably work on packaging it into a single API interface DLL. Still wonder why Hyperion/Oracle wouldn't/couldn't do it. The reason is that .NET runs in a managed code environment vs the unmanaged environment for C / VB. Anytime you make a call in .NET to unmanaged code, there is quite a bit of overhead translating the calls across the managed/unmanaged boundary. The unmanaged API has many operations where there are many, many calls to retrieve the information and each call needs to transition across this boundary. This will kill performance. Add in the fact that you will be re-wrapping the calls when you upgrade plus you will have to deliver the entire runtime environment. In other words, the benefits of .NET have all been minimized in your approach.
Tim Tow
Applied OLAP, Inc 
We were able to get done what we needed through 2 means. (and ended up sticking with the first of these)
1) Use api calls directly from .net (which did require converting the declarations of all functions in the esb32.bas file to vb.net)
EsbOtlOpenOutline - This function took about 80% longer than through Excel but all other functions seemed as fast or faster. Net performance was comparable to the same through VBA or VB6 code.
Our use of the API for this system is limited to about 30 of the calls. Many of these:
And tens of thousands of thess
2) Make a standard vba addin to be used as a pass through for API calls.
This used all the same functions as #1. Performance was maybe 1% slower acoross all functions but certainly not a significant setback and that was more than accounted for by the security of doing it in managed code.
I do agree that this method of using the API from .NET does require the client beign isntalled but in practice all of the users of this implementation are analysts that use the Essbase add-in anyway. Also, transactions that go nuts on the server would be bad for development in .NET such as outline manipulation. But for client tools for sending and retrieveing from the database, performing calculations, mass lookup of member info, etc, usign the API from VB.NET has been fine. 
One thing I would suggest if using Essbase in a VSTO app. When readign a sheet, dump it in to a 2 dimensional object and when writign to a sheet, use the same and then post that to excel or post it to a recordset and use the CopyFromRecordset method. For us that dramatically increased performance to the point that in all aspects our VSTO essbase excel add-in is faster than our vba one

Calling vb .net dlls from apex

Is there any way to integrate vb .net dlls in apex or 10g? Previously I've used the com wrapper to successfully implement vb 6.0 libraries, but I'm not sure how to do this with vb .net. 
Can you expand on 'integrate'? What precisely do you mean by that? 
This was originally a legacy VB 6 application that we are migrating to apex. I need to call 3rd party and in-house applications from the apex/oracle environment. With the older vb6 dlls, I was able to do this with Oracle's com automation feature. VB .net manages registration differently and I'm not sure how to proceed. Does the com automation feature support .net? Does apex have some other module to accomplish this?
Thank you for your help. 
Application Express renders the page on the users machine, how exactly do you want the VB .net dll to work from there? Remember the page runs in a browser session, it's not a desktop client application type of situation.
What do the dll's do?
The more information you can give the better really, there may be far better alternative ways to do this. 
With the com automation feature, the dll calls are made from plsql thru exproc. In this senario, Application Express simply provides an interface to launch the plsql. I guess I'm asking if Application Express provides additional packages that support vb .net.
The dlls extract data from oracle, perform a variety of calulations and uploads the results. Additionally, they provide support for a 3rd party (ESRI) spatial data format. 
I'm confused now...if you're calling the dll's via extproc (i.e. they reside on the server and you're calling them via PL/SQL) then the fact you're calling them via an APEX application shouldn't make any difference.
In other words, if you are already able to call the dll's via PL/SQL, then you should be able to use them from your APEX applications without any significant problems (since you would just call the same PL/SQL). 
Sorry for the confusion. In the original application, these dlls where launched from the desktop. If I use an APEX application, I need to move the dlls to the oracle server. I have been successful in this migration with the older VB6 dlls, but the lastest libraries built in .net do not work.
So my question is - Does APEX have any packages the provide similar support for .net dlls or does anyone know how to use .net with the com automation feature?
Oracle 10gR2 on Windows can call .Net code:
I haven't tried it. 
Hi Jim,
Ahhh ok...the smoke is clearing a bit now ;)
Have a look at the following AskTom thread, particularly the reply from Mark A. Williams -

VB API vs. Java API

I?m new to the Hyperion Essbase world via a new position. Currently, we?re using the Visual Basic API for automation purposes, i.e., updating substitution variables, maintaining members, and simple data retrieval.I?ve read on this site repeatedly about the Java API. Is this going to replace the Visual Basic API? If not, when we move to .Net should we use the Java API to retrieve data for our Web applications? Will there be an API in both Java and .Net? 
Personally, I would use the Java API for this.. If you are a VB person, the initial learning curve is steep (at least it was with me! <BigGrin>... However, you gain the benefit of portability of your code (i.e. it should/will run the same in Windows vs Unix vs Linux) so you could get great benefits in the future, particularly if you ever change database platforms.. Tim TowApplied OLAP, Inc 
Go to your Software Downloads site or the Hyperion Download Center and download "Essbase Enterprise Services" which is the container for the Java API (and which has been renamed "Essbase Deployment Services" or "EDS").. Only one portion of EDS requires a license separate from your Essbase licenses and that is the "High Concurrency Option" which provides database clustering, load balancing and fail-safe rollover capabilities.Install EES, configure it to be able to access Essbase OLAP Servers and then look at the sample code in the ees\samples subdirectory. Good Luck!Tim TowApplied OLAP, Inc 
If you're going to be doing JAVA and .NET you also might want to look at a product named JANEVA from Borland Software.-Peter

Viewing reports

I'm completely new with tools from Hyperion. I was wondering if it is possible to integrate the viewer with other applications, so that the user can easily pick a report from his desktop app and run it. Are there COM objects or anything in that area? We would be working with either .NET or Delphi.Thanks,Luke 
Hi Luke,Were that it was that easy... <sigh>.If you have a third party tool like Business Objects or Cognos, you have some of that capability, but direct connections to .NET and Delphi, I don't think so. Hyperion uses the Java API, and supports a lot of capability there (and depending on the tool, pre-made COM objects, as well).If you don't have a third party tool, you'll need to roll your sleeves up a little more, and dig deeper into the Java stuff, but it only hurts a little. :)

ODP.NET 11g with Instant Client (why so big size?)

Hi folks,
Perhaps this posting should be in the area of "Instant Client" but I hope some of you may have thought about the same issues we have.
We've managed to do a ClickOnce deployment of our Windows Forms client .NET application including ODP.NET 11g and the Instant Client (both part of the XCopy installation).
Our question is: "Why is Instant Client so huge? oraociei11.dll itself is 106MB. Couldn't Oracle provide a better packaged Instant Client specially designed to work with ODP.NET? Couldn't they trim this massive DLL?"
Any thoughts will be greatly appreciated!
The actual ODP part is just Oracle.DataAccess.dll and OraOps10/11/w.dll. ODP still relies on an Oracle Client install to actually connect to the database and do work, and that's the part you're looking at, as I'm sure you probably know and probably also know that even that is very recently added functionality.
As for reducing the size of Instant Client, I agree with you that there shouldnt be any reason that a 2M dll should be able to do the same, but it's not the ODP guys that'd do that, its the [instant] client guys, at least until maybe some day our developers come out with a fully managed provider. crosses fingers.
I am also highly interested in a reasonably-sized yet fully-functional managed .NET provider that is ClickOnce deployable. My vision is that it would talk to either a .NET server that has the 'real' Oracle Client or, in my case, to a Java service running on Windows/Unix/Linux.
My product is a .NET Smart Client that talks to Hyperion Essbase but also, at times, talks to relational sources; I have already written a Java wrapper/.NET proxy that has read-only access; I may end up writing my own provider for read/write access.
Tim Tow
Applied OLAP, Inc 
do you think it would be possible to build a provider in plain managed code? How would talk to sdp for example? The client is not TCP only but supports 4 Network Protocols.
Yes, it is possible.. I haven't started on my provider yet but what I am thinking of writing would use a thin (ClickOnce-deployable) set of wrappers on the client which would talk, in my case, to a Java servlet.
The servlet would take the requests, submitted via http/web-services, and translate to the appropriate real SQL calls using Hibernate Object/Relational Mapping ("ORM") technology (or perhaps the new Java Persistence API (JPA), to form the 'real' SQL that will then call the RDBMS; using Hibernate/JPA will allow me to target any backend database that my customer demands; they don't all use Oracle (yet!).
Note: there is a .NET version of Hibernate called NHibernate if you require a .NET server. There is also new ORM technology in VS 2008 called LINQ; I haven't worked with it.
I just went out and read a blog posting by an old acquantence in the MS world, Roger Jennings, on missing features on VS 2008. It appears that LINQ is not quite cooked compared to NHiberate; it sounds like you can only use it with SQLServer.. I would expect that NHibernate would support more databases; the Java Hibernate version supports something like 20 different backend databases. I have used the Java version of Hibernate with Oracle (10g/11g), MySQL (various 4.x and 5.x versions), SQL Server (2000 and 2005) and DB2 (version 8 on Windows and an unknown AS400 version).
As far a writing a provider, here is a useful link:
Tim Tow
Applied OLAP, Inc 
This is all very nice, but how would this work with Oracle Objects?
Not just Strings, Numbers and Dates, but retrieving SDO_GEOMETRY for instance?
What about other Objects like Persons, Employees, how would these flow/translate through Hibernate/NHibernate or even LINQ? 
I don't know how it would work with Oracle Objects as my expertise and Oracle ACE Director designation is due to my work with the Hyperion Essbase OLAP Server.
That being said.. We are using Hibernate to persist Java representations of metadata to a relational database for our Dodeca product. The metadata may consist of many different type of objects including report definitions, connection definitions, Excel spreadsheets and even add-ins written in C#. The transport that we use is xml over http and it works very well.
I have also written some wrapper code that allows me to pass:
1. a Hibernate connection profile; and
2. a sql query; and
3. a 'mapping' of the columns in the query
to Hibernate; the process connects to the appropriate database, executes the query and returns the result as XML in MS Dataset format. While this approach works fine for what I am doing right now, I am looking to write a full provider to add some new capabilities to our product.
BTW, you can see a couple of Dodeca screenshots at http://www.appliedolap.com/default.asp?ID=49.
Tim Tow
Applied OLAP, Inc 
Thank you all for your thoughts.
One of our requirement is that we do not use N-tier architecture and provide a lightweight client-server architecture. Oracle Database being the server and multiple ClickOnce-deployed applications being the clients.
Although Object-Realtional mapping frameworks are very useful, they still present an overhead and burden performance. In our case we have our business logic/rules in Oracle stored procedures where most of the complexity resides and our clients are relatively thin (we just have very simple client-side validation and record maintenance routines) and there is no real need of having a Value Object layer.
Still, your ideas are valid for N-tier applications.
Our needs are quite different but, given the needs you have, perhaps the OraDirect.NET provider would help you.. http://www.crlab.com/oranet/
Tim Tow
Applied OLAP, Inc.