About archive domain graph errors

There are several types of archive domain graph errors that can occur:

  • Graph validation issues that occur during server startup caused by incorrect entity type definitions
  • Runtime issues that occur during a PolicyCenter archive operation caused by a failure to store or retrieve archive data correctly

Graph validation issues are either fatal errors or non-fatal warnings:

  • Validation graph errors do not permit the application to start. PolicyCenter logs the error but does not continue the startup process.
  • Validation graph warnings generate log entries but PolicyCenter continues to start.

Starting in development mode with domain graph errors

Development mode

By default, PolicyCenter will not start in development mode if there are any domain graph errors. This is true even if archiving is not enabled.

There is an application configuration parameter that controls startup behavior as it relates to domain graph errors. By default, this parameter is set to false. This means PolicyCenter will not start in development mode with domain graph errors. You can set this parameter to true, which allows PolicyCenter to start in development mode, even if there are domain graph errors. The domain graph errors must still be corrected, but you can use this parameter to defer the fixes to a later point in the implementation.

The application configuration parameter is named AllowStartupInDevelopmentModeWithDomainGraphErrors.

Production mode

In production mode, PolicyCenter will not start if there are domain graph errors. These errors must be fixed, even if archiving is not enabled.

Resolve archive graph errors

About this task

Guidewire recommends the following workflow to use in correcting fatal validation errors with the archive domain graph that occur at server startup.

Procedure

  1. Stop the application server.
  2. Ensure that archive logging is set to logging level DEBUG in log4j2.xml. If necessary, enable archive logging or add this functionality if it is missing.
  3. Disable archiving by setting configuration parameter ArchiveEnabled to false in file config.xml.
  4. Start the server in development mode.
    By starting the server in development mode and disabling archiving, it is possible to start the application server even if there are archive domain graph errors. PolicyCenter treats all issues with the archive domain graph as non-fatal warnings. It writes these warnings to the application console log, or, if redirected, to the server log.
  5. Within PolicyCenter, navigate to Server Tools > Info Pages > Domain Graph Info.
  6. Click Download to generate a ZIP file that contains the following:
    • An index file that contains links to the other download files.
    • A log file named construction.log that details how PolicyCenter constructed the graph.
    • A domain.dot file that provides a representation of the archive domain graph in DOT format.
  7. Using these tools, work through the reported warnings until PolicyCenter reports no more issues.
  8. Enable archiving by setting configuration parameter ArchiveEnabled to true in file config.xml.

Results

It is now possible to start the application server with a fully valid archive domain graph.

Resolve archive graph warnings

Before you begin

Before you attempt to correct any non-fatal issues with the archive domain graph, first ensure that you have eliminated all fatal errors in the graph.

About this task

Important: Guidewire recommends that you review the Warnings tab on the Server Tools Domain Graph Info screen for issues every time that you make changes to the PolicyCenter data model.

Procedure

  1. After the server starts successfully with no archive domain errors, perform a test archive operation.
  2. If any runtime errors occur, correct those issues before continuing.
  3. After no more runtime errors occur, navigate to Server Tools > Info Pages > Domain Graph Info within PolicyCenter.
  4. Review and analyze any warnings shown in the Warnings tab.
  5. Fix these issues as appropriate.

Results

The end result is that there are no more warnings remaining on the Warnings tab on the Domain Graph Info screen.

Resolving issues with custom archive entities

If you add a custom entity or entity extension to the archive domain graph, you must not violate any of the rules that govern the ownership relationships in the graph. Otherwise, you can cause graph validation errors that can prevent the PolicyCenter server from starting.

The following list describes how to resolve the common archive domain graph issues.

Issue

Resolution

More information

Custom entity does not implement correct delegate

Ensure that all custom archive entities implement the Extractable delegate. Also, ensure that any custom entity type you create that can be both inside and outside the archive domain graph implements the OverlapTable delegate.

Foreign key ownership relationships cause cycle in graph

Reverse the link ownership direction on one of the foreign keys that cause the ownership cycle error. To change a link direction, use the archivingOwner attribute on a foreign key.

Foreign key link from outside graph to archive root in graph

Set the archivingOwner attribute on the foreign key to source. This prevents PolicyCenter from attempting to archive the linked entity during an archive operation.

Foreign key link from outside graph points to non-root archive entity in graph

Do the following:

  • Set the archivingOwner attribute on the foreign key to none.
  • Add a CrossDomainPlublicID tag to the foreign key that specifies an alternate column to hold the PublicID of the entity instance

The CrossDomainPlublicID tag forces the creation of an additional column on the entity to store the publicID of the target archive entity. PolicyCenter requires this ID in order to re-establish the foreign key link upon retrieval of the PolicyPeriod graph instance.

It is possible that there are other issues with the data model that you must resolve before you can successfully archive your custom entity type. For example, suppose that an entity outside the graph has a foreign key that points to an non-root entity inside the graph. This foreign key has its nullok attribute set to false. As such, it is not possible to use a CrossDomainLink tag to resolve the issue. Instead, set the nullok attribute on the foreign key to true to resolve the issue.

Defining a cross-domain tag

Suppose, for example, that you create a custom TestAccount entity type that is outside the archive domain graph, meaning that it does not implement the Extractable delegate. Entity TestAccount has a foreign key link to a custom Charge entity, which is inside the graph. In this case, the foreign key links an entity type outside the graph to a non-root entity type inside the graph.

This situation causes a validation error at server startup. To resolve the issue, do the following:

  • Set attribute archivingOwner to none on the foreign key.
  • Define a cross-domain tag on the foreign key.
  • Add a PublicID column to store the public ID of the archive entity deleted during archiving.

The following entity metadata definition illustrates these concepts.

<?xml version="1.0"?>
<extension xmlns="http://guidewire.com/datamodel" entityName="TestAccount"> 
  <column name="ArchivedChargePublicID" nullok="true" type="publicid"/>
  <foreignkey archivingOwner="none" fkentity="Charge" name="Charge" nullok="true"> 
    <tag name="CrossDomainPublicID" value="ArchivedChargePublicID"/>
  </foreignkey>
</extension>

Defining a revisioned entity from a purge-only domain graph tag

PolicyCenter generates a validation error at server startup if a purge-only domain graph attempts to include a revisioned entity under the PolicyPeriod entity. This is because the PolicyPeriod domain graph, and any super-sets of that graph, can include revisioned entities. To suppress this error, add the data model ExcludeFromNonRevisionedOwner tag to the foreign key and set its value to true.

The following entity metadata definition illustrates these concepts.
<?xml version="1.0"?>
<extension xmlns="http://guidewire.com/datamodel" entityName="CostExt">
  <foreignkey archivingOwner="target" fkentity="Transaction" name="Charge" nullok="true">
    <tag name="ExcludeFromNonRevisionedOwner" value="true"/>
  </foreignkey>
</extension>
In this example, notice that the code defines the following:
  • A foreign key from CostExt to Transaction.
  • An ExcludeFromNonRevisionedOwner tag with a value of true.