[HAETSE: Restructure information to different targets. This document is too long, too unfocused.]
Application Search is a concept for finding and navigating to IFS Applications business objects using text search. This gives the user more freedom to perform a search without knowing exactly where, or in which attribute, certain text is stored.
The purpose of Application Search is to quickly find and navigate to IFS Applications business objects that you don't know the exact search string for.
The architecture of Application Search is as follows:
A Search Domain is one or more entities grouped together as one object. The entities are grouped together with relations. These relations are used to traverse the Search Domain during indexing. Each Search Domain consists of one and only one master entity and aggregates and references to this master entity or its children.
Example of a Search Domain CustomerOrder:
The text below should be formatted as explaining text to the picture
CustomerOrder is the master LU and it has an array of CustomerOrderLines and references to CustOrdCustomer, SalesPartSalesMan and CustomerOrderAddress. SalesPartSalesman has a reference to PersonInfo.
Each Search Domain consists of:
A Search Domain group is defined by an administrator as a means for users to easily search in multiple related search domains without having to select all of those search domains manually. As an example, suppose there are two search domains for finding invoices - Customer Invoices and Supplier Invoices. Instead of having to select both Search Domains when searching among all invoices, an administrator can define the group Invoices, grouping both Customer and Supplier invoices in one group.
Search Domain groups are defined using IFS Solution Manager.
Each instance of a Search Domain, that is a row in the master entity and its child rows, is considered to be a document. This means that a document is the smallest part that can be indexed. A document is in fact an XML document where the entities and its attributes form the XML document structure.
A document is the smallest part being indexed and all search hits within a document point to the master entity within the Search Domain.
A quick overview of development process is described here. Details can be found in the Foundation1 Development Guide
Note: This is only available on sites with an IFS Development License.
During code generation one PL/SQL package is created which is dependent on the meta data in IFS Developer Studio. At the same time, Foundation1 runtime meta data is created. This meta data will be registered when deploying the Search Domain.
The PL/SQL package and Foundation1 Search Domain meta data is deployed into the database by running the api and apy file created during code generation.
Indexing is done in such a way that Oracle Text calls the generated PL/SQL package indexing method for each master entity record that shall be indexed. The PL/SQL package indexing method then creates an XML document that Oracle Text indexes using a XML filter. The data in the XML document is created by the PL/SQL package index method browsing the Search Domain, starting with the master and then followed by each aggregate and reference until all data is found. The master, aggregates and references create nodes within the XML document. Also, the attributes to be indexed create nodes within the XML document and that data itself becomes data in the attribute's XML nodes. The XML document is then used to create the Oracle Text index.
Example XML document from the Users search domain:
<Users xmlns:xsi="http://www.w3.org/2001/XMLSchema">
<FndUser>
<Description>Juan Pablo Montoya</Description>
<Identity>JUAN</Identity>
<OracleUser>JUAN</OracleUser>
<WebUser>JUAN</WebUser>
<Properties>
<FndUserProperty>
<Value>SYSTEM-DEFINED</Value>
</FndUserProperty>
<FndUserProperty>
<Value>SYSTEM-DEFINED</Value>
</FndUserProperty>
</Properties>
</FndUser>
</Users>
A Search Domain is maintained in IFS Solution Manager. All Search Domains are disabled when delivered, meaning that no triggers or scheduled tasks are enabled, nor is the Oracle Text index created. A disabled Search Domain cannot be used to search for business objects in any of IFS Applications clients.
A Search Domain is enabled in Solution Manager by scheduling a task that is run once. This is handled by a scheduled task because you probably want to enable a Search Domain when the system is running with low load. Enabling a Search Domain also creates an empty OracleText index. At the same time all rows in the main view if the Search Domain is made unsynchronized. To get all rows indexed you need to synchronize them into the index.
Three Scheduled Tasks manage the following items:
Rebuilding the Oracle Text index
Sometimes one may want to rebuild the whole index (meaning re-indexing all documents
within the Search Domain). This should be done when the Search Domain definition
has been changed. This is considered to be an operation that would normally
not be necessary, so this task can normally be disabled (but by default it is
scheduled to run once a month).
There could exist specific search domains where rebuilding of the index is required
relatively frequently - refer to any release notes regarding the enabled search
domains.
Note! Rebuilding an Oracle Text index means that the related table is locked for DML operations (inserts, updates and deletes). This means that when rebuilding an Oracle Text index, IFS Applications cannot perform business transactions against this table. This task should therefore be scheduled to run at night or during non-peak business hours.
Search Domain triggers are created for the master entity and aggregates to the master maintained within the same entity (meaning that aggregates belonging to other entities don't have triggers automatic created).
The aggregate trigger works in this way - If any attribute, used in the Search Domain, is added, changed or removed the trigger updates the master record meaning that it is marked for synchronizing.
Application Search can be used when entering any of IFS Applications clients. There are two different ways of using Application Search:
There are two types of user security related to Application Search:
Search Domain security defines which end-users have the right to use which Search Domain. This is done in different ways depending on the client used.
If the end-user has the right to the use the view connected to the form or the web page, then the user has the right to use the Search Domain based on that view.
If the end-user has the right to the use the activity maintaining the master entity the user has the right to use the Search Domain.
Search Domain data security controls the right to see data within the business object. This security differs a bit when using LUs or native entities.
Security is maintained by using the view, connected to the master entity, during search. This view is responsible for filtering which rows the end-user is allowed to see or not see.
The following restrictions is valid for Search Domains today: