Alerts enhancements in the version 2.5
Contents
In the version 2.5, the creation of alert triggers required to keep results listings updated, is moved to the server. It means that along with the standard Shell listings, I4 search results update to alerts. The configuration for the Shell listings hasn't changed. To enable I4 listings to update, add the !alertConfig section to the !searchContext configuration, e.g. <searchContext Articles" ...> <alertConfig refreshOptions="RefreshOnAlert MonitorContainer" containerReferences="folderObject.folderRef" /> The alertConfig attributes are: •refreshOptions: indicates how an alert is to be handled as well as what is to be monitored. Can be a one of the *OnAlert values combined with one or more of the Monitor* values: oIndicateOnAlert: the results are not refreshed, but a bell icon is displayed in the refresh button indicating that the listing is out of date oRefreshOnAlert: the results are refreshed automatically oMonitorObject: the listed objects are to be monitored for changes oMonitorCheckInCheckOut: the listed objects are to be monitored for check-in/out operations •containerReferences: identifies the attributes on the listed objects that are container references, e.g. folderObject.folderRef or archiveObject.sourceRef. If this is specified, the containers are monitored for send-to and sent-from actions; this allows listings of folders to be updated when new items arrive in it. •objectReferences: identifies objects referenced by attributes on the listed objects, e.g. articles.txts or page.layers. Use in combination with objectReferencesRefreshOptions. •objectReferencesRefreshOptions: indicates what operations on the objects identified by objectReferences raise an alert. Options are one or more of: oMonitorObject: any change to the referenced object raises an alert. oMonitorCheckInCheckOut: check-in/out operations on the referenced object raises an alert. •objectReferencing: identifies the attributes of objects that are referencing the listed objects, e.g. pagePreview.pageRef. Use in combination with !objectReferencingRefreshOptions. •objectReferencingRefreshOptions: indicates what operations on objects identified by objectReferencing raise an alert. Options are one or more of: oMonitorObject: any change to the referencing object raises an alert. oMonitorCheckInCheckOut: check-in/out operations on the referencing object raises an alert. The containerReferences require that values are supplied by the current values specified by the search form. Typically, the containerReferences is "folderObject.folderRef", i.e. the folder containing the listed objects; for this to work, a control in the search form needs to identify the control that selects the folder - this is enabled by the addition of the currentValueObjectType attribute that contains the name of the object type in question, e.g: <searchForm> <ssc:and> ... <ssc:treeObjects path="gn4:folderRef/@idref" attributeFullName="folderObject.folderRef" ... currentValueObjectType="folder"/> The currentValueObjectType can be applied to dropDownObjects, checkBoxesObjects, autoComplete, suggest and treeObjects controls. For the shell listings, no configuration need to be changed, however it is possible to control where the management of the alert triggers is performed via the AlertMethod attribute that is available on the BaseQuery or DirectoryStyle element, e.g. <BaseQuery AlertMethod="Local" ...> The AlertMethod attribute can have the following values: •Default: the default alert management mechanism is used (Server) •None: no alerts are created •Local: alerts are created on the client - this was the original method •Server: alerts are created on the server. If specified, the DirectoryStyle AlertMethod attribute overrides any specified in the associated BaseQuery. |
In the version 2.5, we improved the management of deletion of the AlertMessageTable. In previous GN4 versions, in the GN4 systems with multiple IIS, the AlertMessageTable was deleted multiple times by each IIS machine. In the version 2.5 and newer, we improved the mechanism to minimize the number of delete (using gn_ModifiedTable to keep the last delete date or a lock to avoid multiple deletes. We introduced the new settings Web.IsPrimaryApplication, Web.PrimarySiteName and Web.PrimaryApplicationVirtualPath . These setting allow to control which instance of IIS can delete outdated content of the AlertMessageTable. Add these settings to the appsettings.xml file. If you do not define none of those properties, then each IIS instance is considered primary as it is assumed that only one instance is active. •If you have multiple instances of IIS, but only one per server then the use Web.IsPrimaryApplication to control the primary instance. This property accepts a boolean value indicating whether the associated instance is primary, e.g. <appSettings> <add key="Web.IsPrimaryApplication" value="true" /> The value should be true on only one IIS server and false on the others. •If you have a single server with multiple IIS applications running on it, then use the Web.PrimaryApplicationVirtualPath setting to specify which virtual path is considered the primary one, e.g. <appSettings> <add key="Web.PrimaryApplicationVirtualPath" value="/I4" /> •If you have multiple servers and the virtual path is not sufficient to identify the correct instance, then the Web!.Primary Site Name can be used, e,g. <appSettings> <add key="Web.PrimarySiteName" value="Default Web Site" /> One or both of Web.PrimaryApplicationVirtualPath and Web.PrimarySiteName can be used to indicate the primary instance. You can also alter the number of items that are deleted from the AlertMessageTable in any single query. The new setting to control it is AlertMessageDeleteGranularity setting in the ServerConfig. By default this value is -1 in which case delete commands will attempt to delete all the matching items in a single query. This may cause deadlocks in cases where there are very many items in this table. Specifying a granularity greater than zero, splits delete commands into multiple queries that delete the specified number of items (using sql's delete top(n) mechanism), e.g. <ServerConfig xmlns="http://www.teradp.com/schemas/GN4/1/ServerConfig.xsd" ... AlertMessageDeleteGranularity="200"> |