About when we developed our first custom component for Maximo Application Framework (aka Graphite)

From a technical point of view, there is no doubt that MAS has introduced many new features and improvements over the old Maximo we knew. During these years, one of those we have invested the most time in is the Maximo Application Framework (MAF, or internally called Graphite Declarative Application Framework), the new framework with which both the modern Role Based Applications (RBAs) included in Manage and the entire set of applications that make up Maximo Mobile are developed.

IMO, MAF is an excellent evolution of the smart approach of the previous Anywhere. The use of an xml grammar agnostic from the target technology is the key to simultaneously having a consistent UI/UX and guaranteed maintainability over time. Crucial in this is the ability to write business logic in pure JavaScript still transparently to the underlying technology. Under the cover, a generator converts xml and JS code into a React application but this is just a technical detail that allows a runtime execution with good performance. Perhaps a future generator will transform source code into something else but it will always be "transparent" for developers and end users.

The use of MAF for the development of RBAs is also allowing the UI/UX of Maximo/Manage to be revamped, and this is something that was really needed. It will not be an easy path, much less an immediate one, but the path is right. Release after release, applications like Work Orders are evolving and one day I think they could meet the famous 80/20 Pareto rule relegating glorious Work Order Tracking to occasional operations.

As consultants with strong developer experience, my team has always been particularly capable in overcoming system limitations when heavy customizations were really needed. Since its appearance we have therefore approached MAF in the same way we did with Maximo's GUI and with the many technologies that have been used over time in IBM's various mobile products: understanding the general philosophy, in-depth study, ability to respond quickly to configuration needs (e.g., the classic addition of custom fields in a screen) until recently to customization with components created from scratch. Just about custom component I want to tell you about our first case study.

First, it was an "internal" case study because we do not yet have such a large and demanding installed base that requires this kind of solution. NB: it is always preferable to adapt yourself and at most configure Maximo and not treat it as a development environment. That said, one still needs to study and prepare oneself in order to be able to respond adequately even to "odd" customer requests. Or to be able to create new generic add-ons. So we envisioned a new functionally simple but nontrivial component to touch all aspects of the case. The component shows on a floor plan the position of an asset; e.g., a fire extinguisher on an office floor map. I am well aware that this request is addressable with the use of ArcGIS indoor maps but not all Maximo clients are also ESRI customers.

The requirements that guided the creation of the component were:

• be a native extension of the MAF toolset
• allow the display of an asset in the floor plan
• allow editing of asset placement in the floor plan via mouse and touch gestures
• leverage "datasource" objects for visualizing floor plan and asset placement editing
• adapt to different screen sizes and resolutions in line with responsive design of MAF

We used the React library so that the custom component:

• displays a drawing in SVG format (i.e., the floor plan)
• handles resizing of the drawing
• supports drag&drop of an element (rectangle, polygon, circle, etc...)

Then thanks to the MAF datasources, the component retrieves the floor plan and coordinates of the asset. For simplicity, the drawing is a blob associated with the location while the coordinates are stored a couple of asset-specs. Registered the component in the MAF Configuration application, it can included in an app using its own tag "planimetry-viewer":

In the example, the component is placed in a "border-layout," specifically in a "middle" tag to help with alignment at the UI level and have the ability to have it take up the entire page. The component tag receives the following values as attributes that will be passed as properties:

• assetDS: data source that contains the asset and spec info for the coordinates
• planimetrySvg: field that contains the SVG of the planimetry to be displayed
• planimetryScale: field containing the scale to be used for displaying the asset icon
• id: the autogenerated attribute representing the unique ID of the component

To the end user of the app, the end result looks like this:

The star indicates the location of the fire extinguisher. If not yet positioned, it is red. By moving it with the mouse or fingers it acquires a position in the map by becoming blue. The final position is stored in the asset-specs so that it is available in subsequent views.

The creation of our first custom component allowed us to better understand several internal aspects of MAF. Especially the use of datasources is straightforward for known cases but can be nontrivial when dealing with scenarios without examples to draw from. After all, experience is gained in the field.