We have been working with the new File P8 Daphne API for quite a while now, in our own product development and also in customer projects. I noticed that there are some pitfalls that can cause some trouble if you are new to Filenet or Daphne. This article tries to list the 5 most important mistakes you can make:

Although they are called GUIDs (global UNIQUE identifier) by FileNet, they are ambiguous within the ObjectStore. An object ID is only unique within its class (and sub-classes). But there can be objects of sibling classes in the same ObjectStore that have the same ID. When creating a property from a template for example, FileNet creates a new object of a PropertyDescription sub-class that has the same ID as the PropertyTemplate object.

It is an obvious fact that every P8 ObjectStore has its own class hierarchy. This class tree also contains all user defined classes as sub classes of "Document", "Folder", "CustomObject" and others.

There has been a fundamental change in the way how Authentication is handled between the FileNet Buzz API that came with P8 3.5.x and the new Daphne API architecture used from P8 4 on. In Buzz, Authentication information is attached to all Objects. Every operation on an object is executed in the context of the user that created the session this object has been retrieved from. In Daphne, user authentication is set up in the current thread. This method is closer to JAAS and it enables the same object to be used in the context of different users.

FileNet introduced an entirely new API architecture with their P8 4.0 release. Many people refer to this new API often as FileNet-4-API while the old architecture is called FileNet-3-API. The problem is that the old API architecture is still available on FileNet 4 and even on FileNet 5, although not supported.
After digging in the documentation, I found the internal codenames used by Filenet for these APIs:
P8 3: Buzz API
P8 4: Daphne API
Using these codenames to refer to an API architecture is more clear than using this "FileNet-4-API" term.

While working with the FileNet API, we recently found a bug that caused us some headache. I document this in our blog to help other out there that might have the same issues.
Every FileNet object in the API has a property cache attached to it. So when getting a property from a FileNet object, the API first checks if this property is already in the cache and performs a RPC to the CE server only if the property is not available. This cache is initially populated with the requested properties when the object is fetched, e.g. by a search query.