are supportive resources.
, but supportive resource has none of them. These two kinds of resources are associated with each other, especially the supportive resources cannot be existing alone. From sample, we have seen both supportive resources are referenced by full resource through describedByResource as in
Data Rule Validation
Some basic rules are applied in the data segment, let take a look of a straightforward validation: The name of resource has to be unique throughout one application. If you put two resources with the same name, for example here as workorder, it will generate such error message in the middle of building stage.
A java exception will be thrown as MaximoAnywhere has been encountering data rule validation error, here are the possible errors that will appear if the data segment data are not consolidated well enough.
(1) DuplicatedResourceNameException: it is as shown above.
Action to take: Change the resource name, make each resource has a unique name.
(2) IncompleteResourceException: these two attributes
are found to be incomplete, ie, one has value and the other is empty.
Action to take: Either remove both of two attributes or fill both of two attributes with values. The bottom line is, we cannot leave one having value and the other without. Make the resource be either full resource or supportive resource. The action has to be based upon your business requirement.
(3) UndefinedSupportResourceException: In the given describedByResource's value, for example,
cannot find the resource definition for someResource.
Action to take: create a new supportive resource definition with the name as "someResource" in this example.
In current release, this is shown as a warning message, such as
In the future release, this could be fixed up into a java exception as well.
Action to take: Check and make sure the supportive resource is referenced by other resource. If the resource is staled and not used any more, then simply remove it from the artifact.
(5) LinkShapeKeysConflictException: This is the most important and tricky one. As you see this, it means two different spots are trying to reference the same supportive resource, and each spot is trying to assign its own link key to this resource, and their link keys are different, leading the resource unable to decide which link key to accept, thus this exception is thrown.
Here is a typical case to cause such exception:
<attribute name="firstReferenceSpot" describedByProperty="spi_wm:actualtool"
<attribute name="secondReferenceSpot" describedByProperty="spi_wm:worklog"
note: both firstReferenceSpot and secondReferenceSpot are point to the same supportive resource: workLogResource
Action to take: Locate the name of conflict supportive resource in the artifact, search the artifact file app.xml, find out how many places are referencing this supportive resource, the conflict is coming from these referencing spots. If necessary, setup an individual supportive resource for each referencing spot.