This topic describes changes necessary to your 3.5.x Content Engine COM API applications so they can run in a 4.5 environment. If you have already modified your 3.5.x applications to run in a 4.0.x environment, there are no additional modifications needed to run your applications in a 4.5 environment.
Beginning in the 4.0 release, a Content Engine COM API Compatibility Layer is available. The compatibility layer is a client-side API that allows you to upgrade applications written using the 3.5.x Content Engine COM API. The compatibility layer is designed to maximize support for the 3.5.x COM API in a 4.x environment, providing both source and binary compatibility for Visual Basic 6, C++, and script applications, particularly those using non-administrative interfaces. However, because of differences in platform technologies, parts of the COM API are not supported (such as those interfaces that are useful to administrative applications). In addition, you should be aware that because the compatibility layer is an emulation layered on top of the CE 4.x .Net API, it does not provide performance parity with the natively implemented 3.5.x COM API. Therefore, some applications with stringent performance requirements might need to seek an alternative migration strategy (probably, to rewrite directly to the CE 4.x .Net API).
The compatibility layer is provided only as a backward compatibility layer to support existing applications, and can be installed using the Content Engine installer. (See Installing the COM Compatibility Layer below for instruction.) You can also install the compatibility layer on a client system. The COM Compatibility Layer requires Microsoft .NET Framework (2.0) and Web Services Enhancements (3.0) for all COM clients.
Documentation for the compatibility layer is only available as part of a zip file (named FileNet P8 Compatibility Layers for Content Engine APIs Help) on the IBM Information Management support page on www.ibm.com. To download this zip file from the IBM support page, see Accessing IBM FileNet documentation. The documentation consists of the COM API help that was available for 3.5.x, with an updated reference section that reflects the compatibility layer. Note that the Guide portion of the help, as well as the Code Examples, have not been updated for 4.x.
To install the COM Compatibility Layer (CCL) from the 4.5 IBM FileNet Content Engine installer:
If you do not install the CCL during the initial installation, you have the option of installing it later by running the Content Engine installer again. You can also install the CCL anytime by using the Configuration Manager tool.
New object types introduced in Content Engine 4.x releases (for example, Site, Index Area, Virtual Server) are not directly supported by the COM Compatibility Layer. However, it is possible in some circumstances to operate on these objects to a limited extent as GenericObject (see below).
The following COM API object types are not supported by Content Engine 4.x:
These object types and their associated collection interfaces are defined in the COM Compatibility Layer, but there are no implementation classes. Any navigational properties (of supported object types) that, in the existing COM API, delivered a singleton or collection of these object types (such as ObjectStore.FileStores) return a "Value not set" error using the COM Compatibility Layer.
The COM Compatibility Layer does not provide type-safe accessors for properties defined solely in the Content Engine 4.x API. However, the COM API Properties collection does expose such properties. These properties are also exposed in the PropertyDescriptions collection of the ClassDescription for the object. Therefore, for example, you cannot retrieve one of these properties in the following way:
doc.CompoundDocumentState
But can retrieve it, as follows:
doc.Properties.Item("CompoundDocumentState").Value
For a navigational property that delivers a singleton or collection of a Content Engine 4.x-only object type, retrieving the property value through the Properties collection yields either a GenericObject or a ReadOnlyObjectSet collection of GenericObjects.
Properties falling into this category include the Document class additions for compound document support and PropertyDescription/Template/DefinitionXyz.PersistenceType, which is added in place of IsPersistent.
Content Engine 4.x does not support a number of properties that existed in the 3.5.x Content Engine COM API (although in many cases these properties were deprecated). These unsupported properties are handled in the exact opposite way to new 4.x properties; the type-safe accessors remain and behave as described below, but the properties are absent from the Properties collection (and from the PropertyDescriptions collection of the ClassDescription for the object).
The behavior of the type-safe accessors fall into two categories. In many cases, the information that was delivered by the 3.5.x property exists in another form or can be synthesized from state held in the 4.x object, and in such cases the compatibility layer performs such translation/synthesis to produce a compatible value for the property. Properties in this "emulated" category include:
For the remaining unsupported properties, there is no means of synthesizing a compatible value, so the type-safe accessor returns either a "value not set" error or, in some cases, an empty collection. Properties in this category include:
Additional information on removed properties is provided in sections below.
New methods added by Content Engine 4.x to objects supported by the COM Compatibility Layer are not exposed in the COM Compatibility Layer.
Methods supported by the COM API but not by the Content Engine 4.x API are exposed in the COM Compatibility Layer interfaces, but attempting to call these methods will return a "Not supported" error. The following is a list of these methods:
If your existing code uses either of these ObjectStore properties, you must write your own filtering logic based on iterating through the ObjectStore.ClassDescriptions collection or using ObjectStore.GetObject("ClassDescription", "<classname>").
When using the COM Compatibility Layer in Content Engine 4.x, property values are validated on the server rather than on the client side. The effect is that invalid property values are detected when the objects are saved, not when the property values are set.
The principal functional impact is that code like the following will fail differently with the COM Compatibility Layer than under 3.x.
Obj.IntProp = <value greater than maximum permitted>
Obj.Save
In 3.x, a failure will be reported at the first statement, whereas with the COM Compatibility Layer the failure will not occur until the second.
When using Visual Basic and VBScript to access the 3.x Content Engine COM API, a short-cut syntax is supported where a default method invocation can be omitted from certain forms of a statement. Examples of the short-cut forms are shown below, with the corresponding non-shortcut form immediately following (the last example contains two short-cuts):
Set prop = obj.Properties("DocumentTitle")
Set prop = obj.Properties.Item("DocumentTitle")
Set cd = objStore.RootClassDefinitions("Document")
Set cd = objStore.RootClassDefinitions.Item("Document")
obj.Properties("DocumentTitle") = "My Doc Title"
obj.Properties.Item("DocumentTitle").Value = "My Doc Title"
All of these short-cut forms are fully supported by the Content Engine COM Compatibility Layer for
VBScript clients, and (1) is also fully supported for Visual Basic clients. However, there are some
limitations for Visual Basic clients when using forms (2) and (3), depending on how the target object variable (objStore or obj in the examples above) is declared. If the target variable is
DIMmed as Object, forms (2) and (3) both work. However, if the target variable is DIMmed as an
FNCE type (such as FNCE.Document), form (3) does not work at all, and form (2) only works if the
collection property is defined within that type. An example of how form (2) would not work is:
Dim event As ObjectChangeEvent
…
MsgBox event.ModifiedProperties(1)
This code does not work because ObjectChangeEvent does not include the ModifiedProperties
property. However, if the DIMmed type is changed to UpdateEvent, which does include the
ModifiedProperties property, the code works.
In cases where the short-cut syntax does not work, the statement will fail with an error indicating the "wrong number of arguments or invalid property assignment." You can resolve these limitations in your application in one of the following ways:
obj.DocumentTitle = "My Doc Title"
Note that there are variety of circumstances beyond the simple examples given above where this shortcutting limitation can be encountered. As a general rule, any time you get the "wrong number of arguments …" error, it is likely that you will need to adopt one of the remedies described above.
The Visual Basic runtime maps certain HRESULT return codes into its own runtime errors. For example, DISP_E_TYPEMISMATCH is normally converted to runtime error 13, E_INVALIDARG to runtime error 5, and DISP_E_BADINDEX to runtime error 9. This affects the value of Err.Number in any error handling code, as well as the error message displayed. For these cases, the Content Engine COM Compatibility Layer honors the HRESULT return code, but Visual Basic does not map it to the corresponding runtime error. The result is that, for these specific errors, you must modify the Visual Basic code that handles these errors to check for the unmapped HRESULT rather than the runtime error number.
In releases prior to 4.0, certain property-setting operations and methods had an immediately observable side-effect on other properties. In the COM API Compatibility Layer, there is no such immediate side-effect for those properties that are reflected directly through from the Properties collection of the underlying object. In these cases, a save and refresh is required before the sideeffects are observable.
The most notable example of this is the Name property. For most objects, Name is synthetic; it reflects either the value of the designated name property for the object (such as DocumentTitle), or the String version of the object ID if there is no designated name property. In releases prior to 4.0, the effect was that an update to the designated name property was immediately observable in the value of the Name property. However, in Content Engine 4.x, the synthesis of Name takes place on the server, and on the client the Name property is indistinguishable from "normal" (unsynthesized) properties; so any changes to the corresponding name property only become visible in Name after they are saved.
The same COM interoperability features of the .NET runtime that allow the COM API Compatibility Layer to masquerade as the CE 3.5.x COM API also operate in the opposite direction, allowing managed clients (VB.Net or C#) to call COM APIs. Thus, it is possible to write a managed application that uses the CE 3.5.x COM API.
However, such applications do not run when the COM API Compatibility Layer is substituted in place of the CE 3.5.x COM API; they fail when instantiating FNCE.EntireNetwork, with what appears to be a registration error. This is believed to be because of a limitation of the .NET runtime preventing transitioning through the COM interoperability layer twice (once calling out from the client application, once calling in to the COM API Compatibility Layer).
Therefore, such managed clients are not supported by the COM API Compatibility Layer, and would need to be rewritten to use the native 4.x Content Engine .NET API.
A new error handling framework has been developed for Content Engine 4.x. The COM Compatibility Layer maps the .NET exceptions generated using the new framework into standard HRESULT return codes. Exceptions specific to Content Engine 4.x are returned as "E_FAIL".
In most cases, the error codes returned are unchanged from the 3.5.x Content Engine COM API. However, in some cases error codes and possibly error semantics have changed. Applications highly dependent on specific error returns might require some modification.
In 3.x, attempting to access the Permissions property of an object for which the caller did not have READ_ACL, WRITE_ACL, or WRITE_OWNER rights would result in an error. Beginning in 4.0, the returned Permissions list will be empty. When you encounter an empty Permissions list, you must consult the object's AccessMask to see if the list is empty because the caller lacks READ_ACL, WRITE_ACL, or WRITE_OWNER rights. (This applies to any object with a Permissions property.)
The Extensible Authentication Framework was introduced in IBM FileNet P8 3.5 to facilitate integration with Single-Sign-On (SSO) solutions that would not allow the transmission of a username and password to the IBM FileNet system. In IBM FileNet P8 4.0, we introduced a standards-based methodology for authentication using the J2EE Java Authentication and Authorization (JAAS) framework.
If you have implemented the Extensible Authentication Framework in your 3.5 application, for the 4.x release you must write a JAAS LoginModule using the IBM FileNet Web Service Extensible Authentication Framework. Note that this approach does not require any modifications to existing applications, as the existing client-side logic to submit custom values in the username and password fields will remain in place.
You write the custom JAAS LoginModule on the server, conforming to IBM FileNet's 4.x Web Service Extensible Authentication Framework (WS-EAF). This custom LoginModule will extract the username and password values from the UsernameToken in the incoming WS-Security header, and get the same custom values that were used in the 3.5.2 Extensible Authentication solution, and then invoke whatever custom logic is required to authenticate based on those parameters. For more information, see the Web Service Extensible Authentication Framework Developer’s Guide.
In IBM FileNet P8 3.5.x, LDAP directory lookups could be done using a system configured account, or the user context. Beginning in IBM FileNet P8 4.0, directory service lookups based on the user context are no longer supported. If you have an existing application that enumerates users, more results might be returned in the 4.x release (since lookups done using the user context would have returned only those users and groups to which the user had access).
In 3.5.x, the Content Engine server supported a pre-Windows 2000 login format (domain\loginname) through Microsoft-specific authentication APIs. The functionality is no longer directly available through the J2EE application server-based authentication modules. You are limited to what the application server (or the independent authentication provider that it uses) supports in terms of authentication login-name formats.
Content Engine 4.x does not include an OLEDB Provider, which in the 3.5.x release was the mechanism provided for Windows applications to access the search (query) capabilities of Content Engine (either directly or through ADO). Applications requiring this functionality with Content Engine 4.x must seek alternative means:
Content Engine 3.5.x used IIS and ISAPI to implement the WebDAV provider on the Content Engine host. Content Engine 4.x no longer relies on IIS, and instead implements a Java-based WebDAV provider on the Application Engine host. Existing applications calling the WebDAV provider will need to be reconfigured to reference the new location on the Application Engine host.
Publishing via the Content Engine COM API Compatibility Layer is not available beginning in the 4.0 release.
The Content Engine 3.5.x COM API Extensions--which exposed an API to create custom application server publishing applications (for example, a rendition engine or an administrative application)--are no longer used, and are not supported in the COM Compatibility Layer.
The COM API Extensions CEEDocument class is no longer used, and is not supported in the COM Compatibility Layer. Content Engine 4.x API publishing-related methods are on the Document class itself.
Content Engine 3.5.x supported scripts and COM objects for event actions. Beginning in the 4.0 release, event actions must be Java-based. Any EventAction objects that your application uses must be modified to use a Java class instead of a script or a COM object. Furthermore, the Java class must be located on the server; it cannot be on a client and streamed to the server for execution as for CE 3.5.x. (For information on how to create a Java-based event action, see Work with event actions in the Help for Content Engine Administration.) In addition, changes in the following EventAction properties might require modifications in your application:
In 3.5.x, you could specify a value used to order the firing of subscriptions in response to an event via the Priority property on a Subscription object. However, the server did not use this property, and therefore the property has been deprecated in 4.0.
In 3.5.x, a Process Engine filter expression could be supplied with a workflow subscription using the Expression property. This type of filter expression was evaluated by the Process Engine after the workflow event was launched. Because the filter expression evaluation occurred well after the original transaction was complete, this capability was inefficient and often inaccurate. In the 3.5.x documentation, we recommended that you use the FilterExpression property instead, as the FilterExpression property is evaluated within the transaction that initiates the event (before an event is queued).
Beginning in 4.0, the Expression property is no longer supported. During the upgrade to Content Engine 4.x, if the Expression property contains a value, the value is moved to the FilterExpression property (but only if the FilterExpression property was not populated with a value). If both properties are populated with a value, the upgrade tool will not move the contents of the Expression property, but will instead produce a report of these cases.
Note that the Expression property supported certain SQL syntax that is not supported in the FilterExpression property. Specifically, with the exception of the LIKE operator, all other operators requiring a database query (such as the EXISTS operator) are not supported in the FilterExpression property. For a list of unsupported operators, see FilterExpression Property in the Content Engine Java and .NET Developer's Guide.
If your application uses the Expression property, you must modify your code to use the FilterExpression property instead. In addition, if any 3.5.x Expression values included a SQL operator that is not supported in the FilterExpression property, you must resolve these instances by either programmatically setting the value of the FilterExpression property to a string that includes only supported operators or by using Enterprise Manager to correct the value.
Beginning in the 4.0 release, the IsolatedRegion property on the ClassWorkflowSubscription and InstanceWorkflowSubscription classes has been renamed to IsolatedRegionNumber. The old property (IsolatedRegion) is deprecated, but existing code that accesses this property via the type-safe accessor will continue to work.
Content Engine 3.5.x integrated the Verity VDK for CBR. Beginning in Content Engine 4.0, Autonomy K2 (the former Verity product) is integrated for CBR. The following changed search behaviors are a result of integrating Autonomy K2 as the CBR engine:
In addition, the following Content Engine COM API methods are no longer supported as they are administrative functions that are no longer relevant to the 4.x management of CBR:
The following query configuration-related properties on an ObjectStore are no longer supported:
Beginning in the 4.0 release, the functionality supplied by these properties has been replaced with properties on the new ServerCacheConfiguration class:
Any existing code that accessed the ObjectStore properties will no longer function. Either rewrite your code using one of the 4.x Content Engine APIs, or manually set the new ServerCacheConfiguration properties using Enterprise Manager.
In a release prior to 4.0, the QueryOperatorDescriptions property on PropertyDescription* classes was deprecated. Beginning in the 4.0 release, attempting to retrieve this property will return a DMARC_NOT_SUPPORTED error.
Content Engine 4.x has only the StoragePolicy class, whereas the COM API also has subclasses DatabaseStoragePolicy and FileStoragePolicy. Although DatabaseStoragePolicy and FileStoragePolicy are exposed in the COM compatibility layer, objects retrieved from the server (for example, through ObjectStore.StoragePolicies) will always be of the base class, and neither a DatabaseStoragePolicy nor a FileStoragePolicy instance can be created. This will generally have no impact on applications that simply enumerate the available policies and allow one to be selected as the policy for a new document. However, the following will occur:
Beginning in Content Engine 4.0, a File Store is a File Storage Area, and a Hybrid File Store is a Fixed Storage Area. StorageArea is a new abstract class representing a physical content storage location. It has three concrete subclasses: DatabaseStorageArea, FileStorageArea (replacing FileStore), and FixedStorageArea (replacing a hybrid FileStore). FixedStorageArea may can be further subclassed for fixed-content device-specific subclasses (such as IS or Snaplock). You can access the collection of StorageAreas in a non-typesafe manner through objStore.Properties.Item("StorageAreas").Value, which returns an ROObjectSet of GenericObjects.
Beginning in the 4.0 release, because a storage policy no longer (in general) references a single storage area, it therefore cannot be said to identify a particular storage repository type. Therefore, the StorageRepositoryType property on the StoragePolicy class and subclasses is no longer supported. Attempting to retrieve this property will return a DMARC_NOT_SUPPORTED error.
The MoveContent method on the Document and Annotation classes includes a StoragePolicy parameter. Beginning in the 4.0 release, you can pass in either a StoragePolicy or a StorageArea object (which is new in the 4.0 release). If you pass in a StoragePolicy object, the Content Engine COM Compatibility Layer will move the content to the first storage area selected by the filter for that policy.
Content Engine 3.5.x supported Hitachi, Tivoli, and IBM IICE Fixed Content Devices on Windows platforms. The Hitachi and Tivoli Fixed Content Devices are not supported in Content Engine 4.x. If a Content Engine 3.5.x object store uses one of these devices, the 4.x upgrade cannot succeed unless the content on these devices is first moved to a file store or to a Fixed Content Device supported by Content Engine 4.x. In addition, the following Content Engine COM API classes are no longer supported:
In releases prior to 4.0, the FixedContentDevice (FCD) ConfigurationParameters property was a single XML string defining all of the FCD parameters used to configure the various FCD devices. This XML string has been split into separate properties. Each of the FCD-specific properties are on the specific type of FCD (for example, the IS FCD has IS-specific parameters). Additionally, some of the remaining FCD property names have been renamed to be more accurate.
In releases prior to 4.0, attempting to modify properties for which the user did not have appropriate access rights was recorded as an audit failure by the Content Engine. However, beginning in the 4.0 release, the Content COM API will immediately generate an error on the client under these circumstances, and therefore will not record the failed attempt in the audit log. (Only operations executed on the Content Engine server can be audited; failed or successful client operations are not audited by the server.)
Content Engine 3.5.x supported Microsoft ActiveScript technology for document lifecycle actions. Beginning in the 4.0 release, lifecycle actions must be Java-based. Furthermore, the Java class must be located on the server; it cannot be on a client and streamed to the server for execution as for CE 3.5.x. Any DocumentLifecycleAction objects that your application uses must be modified to use a Java class instead of a script. In addition, note changes in the following DocumentLifecycleAction properties:
In releases prior to 4.0, you could delete any DocumentLifecyclePolicy object as long as the DocumentLifecyclePolicy was no longer being referenced by one or more Document instances. Beginning in the 4.0 release, you cannot delete a DocumentLifecyclePolicy if it is being referenced by one or more Document instances or if it is the default policy for a Document class.
Content Engine 3.5.x supported COM-based plug-ins for document classification actions. Beginning in the 4.0 release, classification actions must be Java-based. Furthermore, the Java class must be located on the server; it cannot be on a client and streamed to the server for execution as for CE 3.5.x. Any DocumentClassificationAction objects that your application uses must be modified to use a Java class instead of a COM class. For information on how to create a document classification action, see Understanding automatic document classification in the Help for Content Engine Administration. In addition, note changes in the following DocumentClassificationAction properties:
In 3.5.x, the algorithm used by the XMLPropertyMappingScript object was as follows:
Look for a Processing Instruction named FileNetDocClass.
If it exists, use its value.
Otherwise, look for a DTD with an external specifier.
If it exists, use the value of the SYSTEM attribute (which usually contains a URL).
Otherwise, use the name of the root element.
Beginning in the 4.0 release, the algorithm is as follows:
Look for a Processing Instruction named FileNetDocClass.
If it exists, use its value.
Otherwise, get the expanded QName of the root element in the form of
{RootElementNamespaceURI}RootElementLocalName. (The system looks for this in the XMLDocumentType property.)
If your existing application uses a FileNetDocClass Processing Instruction node in the XML content, no change is required for 4.x. Otherwise, you need to modify the value of the XMLDocumentType property of the XMLPropertyMappingScript object to use the new format:
{RootElementNamespaceURI}RootElementLocalName
For example, if the root element is:
<claim xmlns="http://www.filenet.com/claimSchema">
Then the expanded QName is:
{http://www.filenet.com/claimSchema}claim
In releases prior to 4.0, when an application did not supply a content type value for a ContentReference or ContentTransfer object, the 3.x Content Engine used file extension mappings in the Windows registry along with Microsoft APIs to examine document content. Content Engine 4.x identifies the content type based on a fixed listing of file extensions.
Because Content Engine 4.x uses a set listing of file extensions to identify the document content type, the resulting (identified) content type can be different from that identified by Content Engine 3.5.x. To ensure that an object's content type is identified properly, explicitly specify the ContentType property for existing Content Engine 3.5.x applications when creating or updating a content element.
In releases prior to 4.0, if a user attempted to retrieve a VersionSeries object for which he did not have access rights to the current version, the VersionSeries object would be returned (security checking was bypassed because the VersionSeries object was fabricated on the client side). Beginning in the 4.0 release, if the user does not have access rights to the current version, the COM Compatibility Layer will return a DMARC_NOT_FOUND error.
Content Engine 3.5.x supported Microsoft ActiveScript technology for pre-install/post-install scripts for AddOns. Beginning in Content Engine 4.0, only JavaScript scripting is supported. If your application creates AddOn objects and uses any pre-import or post-import scripts written in VBScript, you must:
In releases prior to 4.0, attempting to move a root folder generated a NOT_SUPPORTED error. Beginning in the 4.0 release, an ACCESS_DENIED error is generated. (Note that the ACCESS_DENIED error is also thrown in 4.x if you attempt to change a root folder's name or delete a root folder.)
In releases prior to 4.0, attempting to update the list of PropertyDefinition objects for a ClassDefinition resulted in an ACCESS_DENIED error. Beginning in the 4.0 release, a NOT_SUPPORTED error is generated instead.
In the 3.5.x release, operations that convert a GUID from a String to the internal form ignored any data after the closing } (brace). For example, the bolded text after the closing brace below would have been ignored:
{1321358E-DD13-4913-A44C-B57659A05C1E}, brown, filenet;cemp:t3: //localhost:7001/
FileNet/Engine;null
Beginning in the 4.0 release, this is no longer the case; any applications relying on this behavior must be updated.
In the 3.5.x release, you could reuse dependent objects and dependent object lists. For example, in 3.5.x you could create or retrieve the Permission objects for one object and then directly use those same Permission objects on another object. Beginning in the 4.0 release, dependent objects and dependent object lists are not reusable. If you attempt such reuse, a runtime error will be generated.
In releases prior to 4.0, if you retrieved the ClassDescriptions property for an ObjectStore, the ClassDescription for that ObjectStore would be included in the collection. Beginning in the 4.0 release, this is no longer the case. However, as in 3.5.x, you can continue to retrieve the ClassDescription for an ObjectStore by retrieving the ClassDescription property on the ObjectStore object.
In releases prior to 4.0, you could retrieve the users and groups in a Realm via the Users and Groups properties. However, because these properties returned exhaustive collections of all users and groups in the realm, we recommended that you use the FindUsers and FindGroups methods instead. Beginning in the 4.0 release, retrieving the Users and Groups properties of the Realm object returns empty collections instead of populated lists and you must use the Findxxx methods instead.
In 3.5.x, it was possible to continue retrieving and setting properties on an object after the object had been successfully deleted with a non-pending Delete() or after committing (with Save() or SaveBatch()) a delete made pending with idmChangeSetPending. Beginning in the 4.0 release this is no longer the case, and attempting such operations will have unpredictable results.
Beginning in the 4.0 release, the Type property on the Domain class is no longer supported. The Type property was meant to indicate the type of IBM FileNet P8 domain (private, public, or workgroup), but public was the only type the Content Engine COM API ever supported.
In releases prior to 4.0, the GCD (Global Configuration Data) was stored in the local file system. Beginning in the 4.0 release, the GCD is generally stored in a separate database instance, leveraging the RDBMS used by Content Engine.
During the upgrade operation from IBM FileNet P8 3.5.x, the DateCreated and Creator properties for the following objects are replaced with the date of the upgrade and the name of the user performing the upgrade, respectively:
The DateCreated and Creator properties are not changed by the upgrade operation for objects that reside within an object store (such as Documents, Folders, and CustomObjects).
In 3.x releases, if you specified a date earlier than 1 Jan 1753 (which was the constraint specified by the PropertyMinimumDateTime property on the PropertyDescriptionDateTime class) for a custom property, the Content Engine server silently changed the date to 1 Jan 1753. Beginning in the 4.0 release, the PropertyDescriptionDateTime class has been updated to reflect the database-specific limits on date/time values. System and custom property values exceeding the database constraints will generate an error. If your 3.5.x application relied on the above-mentioned PropertyMinimumDateTime behavior, you should modify your application to either pre-validate the date/time values, or to catch the error.