IBM Support

The Mechanism of IBM MaximoAnywhere 7.5+ Data Rule Validation Happening At Application Build Stage

Technical Blog Post


The Mechanism of IBM MaximoAnywhere 7.5+ Data Rule Validation Happening At Application Build Stage


(if you find this article is cut off on the right margin, try to switch your browser to chrome and try again)



IBM Tivoli group has just released a maximo mobile product called: MaximoAnywhere, version 7.5, this product is using the IBM Worklight to bridge the core maximo and maximo mobile applications on real devices. Enterprise user needs to install the mobile platform and applications, IBM also provides other installation options, like, worklight studio. If only are platform and applications selected to install, then these are the two folders you will notice in the end.







The sub folder of platform is mobile, where is the place you may conduct various commands of building, deploy, and maintenance of all maximoanywhere components, the contents of mobile folder looks like:










For all details about how to install, build and deploy, please refer to other related MaximoAnywhere documentation, which is not the major part for this article.


The basic ant commands in this folder are

   ant all

   ant init 

   ant all-gen

   ant all-dist

   ant all-deploy


MaximoAnywhere  Application Artifact


As you may see, in the basic ant commands, there is a command, "ant all-gen", by using which, you may generate the full worklight  project where it includes, in this release, two maximo mobile applications



Each application has an artifact file to define the whole application's UI views, data resources and messages.  The path of these two application artifacts are located somewhere, for example, 

         C:\Program Files\IBM\MaximoAnywhere\apps\WorkExecution\app.xml

         C:\Program Files\IBM\MaximoAnywhere\apps\WorkApproval\app.xml

depending on your installation base folder.


The artifact is composed of three parts

   (1) ui definitions

   (2) data definitions

   (3) message definitions


The sample artifact can be simply outlined as as






Warning: do not use this outlined sample as your real business application. The real business app artifact has already been included in the maximoanywhere release bundle.


Data Part Of Artifact


The major thing to cover in this article is to address the data rule validation that is happening behind the scene automatically as you run maximoanywhere command

            Ant all-gen

Note: as you run "ant all", all-gen is also executed automatically without any warnings.


Let take a look at more details about data part. 






Warning: do not use this outlined sample as your real business application. The real business app artifact has already been included in the maximoanywhere release bundle.

As what it is shown above, data segment is a list of concatenated resources. Each resource is basically mapped as a maximo object. The object data will be downloaded from core maximo server to the device, and the device end could have its own local data intruded into the object. The device has its local data store to store all these combined objects, which will provide powerful offline supports to the maximo anywhere applications.


Category of Resources


There are two kinds of resources, full resource and supportive resource. In the example above, the resource of


is a full resource, and the other two of 



are supportive resources.


The difference on that is the full resource has attributes of both




, 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

         <attribute name="materiallist" describedByProperty="spi_wm:wpmaterial"  describedByResource="plannedMaterialResource" />

         <attribute name="toollist" describedByProperty="spi_wm:wptool"

describedByResource="plannedToolResource" /> 



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.


(4) IsolatedRemoteResourceException:

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"
         describedByResource="workLogResource" />
<attribute name="secondReferenceSpot" describedByProperty="spi_wm:worklog"
         describedByResource="workLogResource" />

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.     




You possibly noticed that in the artifact an xml schema is included, as


where it is validating the artifact xml schema only, there is no overlap with the data rule validation addressed in this article. An artifact that has passed xml schema validation does mean it will pass the data rule validation.

All in all, the purpose of data rule validation is to provide maximo customers with a useful pre-stage information as building the enterprise applications by intercepting the errors and potential problems at the building time instead of delaying to the run time, which will be more expensive and time-consuming.


[{"Business Unit":{"code":"BU005","label":"IoT"}, "Product":{"code":"SSLKT6","label":"Maximo Asset Management"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":""}]