When developing a FileNet Open Client application, you must use JiGlue to provide the COM Bridge between the data providers and the Process Engine services (accessed via the Process Java™ APIs). The JiGlue COM Bridge provides the ability to make COM-based VB.NET (or other .NET-compatible language) calls to the Process Java APIs equivalent to native Java statements for nearly all Windows programming tasks.
There are a number of known ASP.NET and JiGlue COM Bridge-related issues and guidelines to keep in mind when creating your Process Open Client ASPX pages and User Controls, including:
FileNet IDM COM objects run under the Single-Threaded Apartment (STA) model. To call IDM COM objects from your ASPX page, to ensure STA threading, you would set the ASPCOMPAT="True" page directive (the default is False). However JiGlue, as a COM object, runs under the Multi-Threaded Apartment (MTA) model. Therefore, for Process applications, when you create your ASPX page, you must set ASPCOMPAT="False" on all ASPX pages that use JiGlue. Setting ASPCOMPAT="True" when using JiGlue can cause random "Invalid callee" exceptions (this is a known ASP.NET JiGlue issue). On the other hand, if you instead use ADO to query the database (for large-scale queries instead of querying queues via the Process API as you would normally do), you must set ASPCOMPAT="True".
The supported JRE must be installed in its default directory in order for JiGlue to work properly. For additional information, see Installing the JDK.
When you use the Step Processor supplied with FileNet Process Open Client and the FnProcessStepProcDP Data Provider, the Data Provider provides the interface to JiGlue, thereby insulating your ASPX page and the User Controls from JiGlue and the Process Engine server. No references to JiGlue should be made outside the Data Provider. If you are not going to use the supplied Step Processor and the FnProcessStepProcDP Data Provider, you need to specify a Data Provider that will provide the JiGlue interface.
Dates returned via JiGlue calls are in UTC-ISO format.
You should not combine multiple method calls to JiGlue in a single VB.NET statement. For example, the following statement will fail in some cases:
JiglueObject1.setABC(JiglueObject2.getXYZ())
If failure does occur, the symptoms and exceptions can be obscure.
To use JiGlue to create and instantiate a Process VWSession object and log on, you might use VB.NET code similar to the following:
Imports Jiglue Public Class FnJiglueSample Protected m_aJiglue As New JiglueUtil() Public Function Logon() As Boolean ... 'Use JiGlue to create a VWSession object and logon Dim aVWSession As Object aVWSession = m_aJiglue.newinstance("filenet.vw.api.VWSession") SetVWSession(aVWSession) aVWSession.logon(strUserName,strPassWord,strRouterURL) ... End Function ... End Class
where strRouterURL is the URL of the Process Engine connection point.
If you want to declare an integer array, be aware that in Visual Basic or VB.NET, an integer is a 16-bit value, whereas in Java (and for the Process APIs), an integer is a 32-bit value. If, for example, you specify a 2-byte integer array in Visual Basic, it might be mapped in JiGlue to java.lang.Short, thereby causing the Process Java API to throw an exception.
The following additional COM-related issues and guidelines should be kept in mind when developing a Process Open Client application:
You cannot type-cast an IDM generic object into other IDM objects (for example, type-casting the object into a document). This is a known .NET issue (it is anticipated that Microsoft will supply a fix for this in a future .NET release). The workaround is to use the hidden IFnxxxDual interface of the object in your type-cast statement.
COM calls from .NET require marshalling, which can negatively impact performance. Therefore, COM calls should be minimized whenever possible.
See also: