Infrastructure at your Service
I already talked about the domain creation in a previous blog, it is nice to start with but of course not enough if you want to understand the domain architecture, its components, and how they are related to each other.
The Documentum installation owner is the operating system user that owns the server executable and other related files along with the OS process when the server is running. It is originally determined when the server is installed, in fact, it is the logged-in user that performed the Documentum installation.
In a previous blog I talked about CMIS in general and showed you what importance it does have in ECM World. In fact, I already experienced CMIS in a project with Documentum and Alfresco involved! The goal was to make the same operations on both ECM from a single interface, so CMIS was the solution. In this blog, I will talk about CMIS with Documentum.
As you know, there is a lot of vendors for Enterprise Content Management systems (ECM) and they all have different interfaces. Content Management Interoperability Services (CMIS) is a standard for improving interoperability between Enterprise Content Management systems.
The first step in JBoss world is to understand these terms and the relationship between each other: Modules, Extensions, Subsystems, and Profiles. Let’s say that the definition of these terms is the same between Standalone and Domain mode. I will explain each term separately then I will show you the difference in terms of profiles management between Standalone and Domain mode.
In this blog, I would like to show you how to setup JBoss EAP 7.0.0 in domain mode. It’s a step to step guide so you can follow the instructions in this blog and build your environment by yourself 😉
Usually, when we speak about Standalone mode we imagine that it can’t be clustered… In fact, with JBoss it is possible, the clustering functionality is configured by default in the HA-based profiles: standalone-ha.xml and standalone-full-ha.xml.
FTIntegrity is used to verify indexing after migration or to get a status after a normal indexing. The tool is a standalone Java program that verifies all types that are registered in the dmi_registry_table with the user dm_fulltext_index_user. By default, the utility compares the object ID and i_vstamp between the repository and xPlore.
At a customer we encountered some issues with FT Search after documents migration. In fact, some documents were not indexed correctly or partially indexed, the need was to know which documents are impacted to resubmit the indexing again. The FTIntegrity tool is not able to give the needed result, so the only way was XQuery search.
At a customer, I received an incident saying that on D2 a document is found by browsing and not found using normal search. The root cause seems to be easy: The Document isn’t indexed?! Not really, you will see it wasn’t easy to find 😉
