An Essbase object is simply a file Essbase uses, such as a database outline, a calc script, or other data. Essbase has an object system which allows you to refer to such files through the API simply by the name, the file type, and the application and database with which they are associated. This allows objects to be manipulated independently of the underlying file system (which may vary between different platforms and implementations of Essbase).
Objects can reside on any Essbase Server or client. A locking mechanism on the server controls access to objects, so that users with sufficient privileges can lock server objects and copy them to the client (using the EsbGetObject() function), edit them, and save them back to the server (using the EsbPutObject() function). Server objects can also be opened without locking for read-only access, but then cannot be saved back to the server. A user can also create or edit objects on client workstations for their personal use, or save them to the server for other users to share. Clients cannot make server to server copies.
When accessing objects through the API, the object name refers to the file name of the object (without any extension). The object types are declared in the API header file in the form ESB_OBJTYPE_xxx (where xxx represents the specific type, as in ESB_OBJTYPE_REPORT). Most objects are associated with an application and database, but some objects such as calc scripts, and rules files can be stored at the application level and used with any database within the application.
Server object files are physically located in the corresponding application or database sub-directory. However, it is not generally advisable to manipulate server object files directly. Always use the appropriate API functions to copy the files locally. Client object files are also stored by default in application and database sub-directories of the directory specified by the LocalPath setting of ESB_INIT_T. These files may be freely manipulated and edited, but you should ensure your program is well-behaved when locking and unlocking server objects which are being edited on the client (always lock an object before editing and unlock it afterwards, whether or not changes are saved).
If you intend to access file objects on a client machine through the API, you need to create alocal context for the API object functions to use. To create a local context, use the EsbCreateLocalContext function, which returns a context handle. This handle can be passed to any of the object API functions instead of a login context handle, and causes the API to perform the requested operation on the local client object system instead of the server. You only need to create a local context once, immediately after your program first initializes the API.
If you create a local context, your program should clean up by calling the EsbDeleteLocalContext() function before terminating the API.