The Maximo Integration Framework (MIF/OSLC) is defined as a framework that provides Web services and service-oriented architecture (SOA) technologies to support application services and coordination between enterprise systems such as synchronization and integration of data between applications. Data transferred to Maximo should already be validated in the external system before being synchronized with Maximo and does not work well with user manipulated data.
Real-time field validation
The integration framework provides error message handling but only once the invalid data has been sent to Maximo. When a user creates a new work order with a Corrective Maintenance (CM) work type and accidentally enters ‘CMN’, the user does not know its invalid until it is sent to Maximo and an error is thrown. Tools like the Maximo 7.5 Automation Script and TRM Rules Manager will not be applied without real-time validation until the data is processed on the server.
Real-time field lookups
The majority of fields in Maximo are associated with a lookup list. This list is validated based on business rules that are enforced by Maximo. The MIF gives you the capability to query data, but not based on the record you are working on. For example, when changing a work order status in Maximo, a user can only change to a status based on its current status. A user cannot change the status to Waiting for Approval (WAPPR) when the work order is already Closed (CLOSE). This built in Maximo business rule cannot be enforced through the MIF until the data is processed on the server. This means that there is more room for error when a user is manually manipulating data on a mobile device. Fields like the GL account will be a pain to manage.
Security
The real power of Maximo security groups is the ability to restrict users’ access to fields, values and even lookups. Along with real-time validation, the MIF doesn’t throw an exception until the data is processed and sometimes it can even surpass all the security restrictions and save to the Maximo database. Security restrictions will have to be manually duplicated on the mobile device and that will negatively impact development time and overall cost.
Workflows
If your organization uses extensive workflows, you are out of luck when it comes to managing work orders and the workflow processes on those records. Workflow in Maximo is a very complicated system and requires a user interface to handle all of the user interactions at any given point in the workflow process. The MIF does not provide any type of user interface.
Batch Processing
This is essential for any mobile access in a disconnected environment because all offline data is stored on the mobile device and once connected, it will synchronize the data with Maximo. The problem is that the integration framework isn’t built for batch processing of large datasets. Batch processing can be done, but it’s limited by the amount of resources on the server. Large datasets can run into hanging server processes and will require a server reboot to fix.
Sessions
Each time you log into your Maximo environment, a Maximo session gets opened specifically for you. This session gives each user a unique identity within the system and is the genesis of all Maximo functionalities. The ability to track and manage these Maximo sessions allows your organization to get a better feel for when users are logging in and out, what they’re doing and when they’re doing it. Opening a Maximo session is not something you can achieve through the MIF.
Maximo Configuration Changes
Most organizations that use Maximo have business needs that change from time to time. These changes are often in the form of new fields within a variety of different applications. If your organization is utilizing the MIF as part of their mobile solution, web services will need to be re-configured and re-deployed each time a change in the data structure occurs. This sort of setup doesn’t lend itself to an agile work environment.
Multiple Sites
If you belong to multiple sites within your organization then switching your default insert site is something you’re probably quite familiar with. Automatic filtering of result sets by site and creating a new record in any application are two main functions that are driven by your default insert site. The MIF is capable of retrieving a user’s default insert site, but changing that site on the fly through the MIF is not possible, because it uses the MXINTADM (Maximo Integration Administrator) account as the default user for all inbound/outbound transactions.
I have read your article and unfortunately, it is full of mistakes and incorrect assumptions.
Real-time validation: Yes, we do perform validation when the transaction is submitted to Maximo. How can we validate a transaction before then? For this reason, best practices is to ensure that you the external system works with the same value sets that are used in Maximo, so a user cannot enter “CMN” instead of “CM”. The onus is on the external system to maintain a valid domain and enforce the domain usage the same way Maximo does.
Real-time field lookups: This can be done as well. However, the example you gave of changing of a work order status has nothing to do with a real-time field lookup. Changing a status in a Maximo work order can be easily done with integration framework. There is even a facility that was exposed just for this purpose. However, you do have to follow the rules when doing so… isn’t that what the value is of having an integration gateway that enforces your business rules?
Security: Bear in mind that the integration framework transaction is NOT a user transaction. Security can be implemented using authentication and/or SSL. Also, the integration super-user (MXINTADM) can be restricted in the same way a traditional user can be.
Workflows: Not sure what you’re talking about here. A workflow process is a completely separate entity from an integration transaction. If a workflow process is triggered by a record showing up in a specific status, then the integration will trigger it as well… so the workflow will start, regardless if its a front-end user or an integration transaction that started it. Furthermore, there are facilities in the integration framework that allow you to remotely start a workflow process from an external system.
Batch Processing: Again, your assumptions are incorrect. I have personally used Integration Framework at many client sites and we routinely loaded millions of rows. It is all in how you configure your system. You can deploy many JVMs and scale the enterprise implementation to any size. The integration framework uses industry-standard JMS queues, which can be configured to use data stores instead of file stores. This allows you to take advantage of the power of the database to store in-flight transactions. You can then deploy multiple message driven beans and adjust the batch size for these beans to optimize memory and cpu loads. There is no way that you’re going to overload a properly-configured environment with mobile transactions. You will overload the mobile device many, many times before you will overload a single JVM running on a server.
Sessions: You can’t track sessions because these are not USERS logging into the system…it is an INTERFACE. User sessions and integration processes are not the same. In a correctly-configured environment, you would actually go out of your way to isolate them. All inbound and cron-task processing should be handled by one or more JVMs that are NOT dedicated to handling UI.
Configuration changes: In a production environment, and especially in a large enterprise one, you would have very strict controls over any and all changes to the schema. Having said this, if your external system conforms to standards and it consumes our WSDL, then theoretically, all you have to do is redeploy the WSDL and the external system would need to consume the new WSDL.
Multiple Sites: I know of no enterprise-level business that allows an end-user to change their default insert site. This is an administrative task, not an end-user task. Also, the default insert site only comes into play if the transaction does not have a site id. Why on earth would you try to insert a transaction via integration that does not have a site id on it?
I hope that you can take the time to become more familiar with the Integration Framework and correct the many mistakes in your article.
You have made all valid points and I agree that MIF is a great INTEGRATION tool but as the title of the article clearly states that it is not DESIGNED for MOBILITY. All of your statements actually reinforces my point. You can use it but it does have limitations. Does Maximo Everyplace or IBM Maximo Mobile use the MIF? It does not.
Real-time validation: You said “Yes, we do perform validation when the transaction is submitted to Maximo. How can we validate a transaction before then?” This question reinforces that MIF is not designed for mobile. I have used MIF and understand all validations are executed when a transaction is sent to be processed, but how does Maximo do it? When a user types an invalid value in Maximo, you immediately get prompted that the value is incorrect and forced to correct it BEFORE saving. This kind of real-time validation cannot be done with MIF and can only be corrected after the transaction is processed.
Real-time field lookups: “However, you do have to follow the rules when doing so… isn’t that what the value is of having an integration gateway that enforces your business rules?” I agree with this statement but only for a person knowledgable with system integrations. Do you think an end user on the business side will understand that when using it for mobility?
Security: “Bear in mind that the integration framework transaction is NOT a user transaction.” Coming from you, this statement sums up my point. Why would you want a mobile solution that is NOT tracked by a user transaction? You can restrict MXINTADM, but do all your mobile users have the exact same security privileges?
Workflows: In Maximo you can route any record by clicking on the “route workflow” button and a dialog opens with a valid workflow action. You cannot do that with MIF.
Batch Processing: I agree server configuration is always a consideration when processing large batches of data, but smaller organizations with less than 100 active users isn’t going to have a complex Maximo setup just for mobility.
Sessions: Again, isn’t this the whole point of mobility?
Multiple Sites: For large organizations with multiple sites, what’s the point of going mobile if a technician out in the field can’t change the default insert site? If you’re mobile, how likely are you to go from one site to another? I have multiple clients using EZMaxMobile with this exact scenario.
This article isn’t to attack MIF, but to explain that it’s not designed for mobile end users. I hope that I have helped you bridge the gap between business users and technology and thanks for reinforcing my point.
Chon, there is no tool that is designed specifically for mobility. You have to build in the validation at the point of entry. Maximo can do it at the point of entry because it is connected to the database. You cannot assume you will always have a live connection in a mobile environment, so you must move the validation of data to the device. The MIF can help you do this by leveraging web service queries. If you design compact business objects and expose them for querying, you could theoretically pre-load a device with enough data so it can survive on its own without a network connection. However you do it, either through a permanent data store on the device, or a live connection, the validation must be done at the point of entry.
Theoretically, you could do this from a connected device. Once the user enters a value, and they go to to the next field, you could perform a parallel synchronous call to the Maximo server to validate that data. If it does not pass validation, then you can use GUI elements (like underline it red for example) to indicate to the user that there is a problem with that value. Its all in how you design the solution… however, something like this can be problematic in a high-latency environment, or impossible in one where you cannot guarantee a persistent connection to the server.
You seem to be locked into this concept of “real time”. However, the whole notion of mobility is that of asynchronous processing, not synchronous. The field technician will go about his day and perform his work and will connect/transfer data as time or network connectivity permits. Your mobile solution needs to be able to provide functionality to the user regardless of the state of connection. Therefore, the design of the solution has to have a temporary data store, and must replicate some business logic from Maximo. There is no way around that unless you settle for offering a solution that will only work with a live network connection.
Security: You’re confusing application security/restrictions, with web service security. The MIF is only exposing a web service and you can secure it by placing authentication credentials on the request header and also by encapsulating the request in SSL and using tokens. As far as application-specific security, yes, your security model in the device will dictate who can do what. I would assume that you would have a few security groups inside of Maximo and that you would give each of these different privileges. You can expose a web service query that will return a security profile for a given user id. What you do with that is up to you and your design criteria.
Workflow: The point about a dialog popping up is why it isn’t valid. The dialog can only be dismissed by a user session. As I have said before, the MIF is designed for integration, not user interaction. There are methods and standard services that facilitate initiating workflows from the integration framework. Not sure if you’re aware of these.
Finally, about batch processing… the title of your article includes the word “Enterprise”, which in my extensive experience and background, usually means more than 100 active users… and more than a single JVM. I stand by my original comment here. If you’re choking your JVM with only 100 active users, there is something wrong with your setup.
Why can’t the technician insert or report against a work order in a different site? As long as he has access to it, the site id should be transparent to him. All he should have to do is look at a queue of his work and pick the work order he’s on. The system knows what the site id is for that work order and that is included in the transaction that goes back to the server.
I have worked with Maximo since it was a 16-bit app written in SQLWindows and in Integration for almost 20 years. Trust me, I know how to bridge gaps between functional requirements and the technology to implement them.
I review your all 8 reasons and find quite useful information about
Maximo Integration Framework, I was concern about security and multiple site and after read your information about that get good knowledge, thanks for the info.
In the current release of RulesManager 5, this is no longer the case. In
fact RulesManager is capable of full access to Maximo Integrations
Before
and After Maximo processes the record. By using the RulesManager
Studio Integration Builder (Our Eclipse environment for development of
scripts for Maximo customization) The Maximo Administrator is given full
scripted control over the Maximo MIF input/output process.
Simple content assisted Scripts are easily developed to modify Maximo
integration objects at any point in the MIF process. (Integration
objects in/out, Mbo creation or skip transactions), as well as direct
access to JMS Queues without the need for Java code.
TRM will be hosting a webinar demonstrating this new capability on July 11,2013 from 2 PM -2:30 PM EST.
Al Johnson
VP Product Development
Total Resource Management
al.johnson@trmnet.com
That’s good to know and thanks for the update Al. Do you have a link to the webinar?
Sorry about that. Here’s the registration link for the upcoming MIF webinar.
https://www2.gotomeeting.com/register/849468586
Al Johnson
VP Product Development
Total Resource Management
al.johnson@trmnet.com
Sorry about that. Here’s the registration link for the upcoming MIF webinar.
https://www2.gotomeeting.com/register/849468586
Al Johnson
VP Product Development
Total Resource Management
al.johnson@trmnet.com
Chon, Since you wrote this in April 2013, has anything changed with MIF in v7.5/7.6 that more easily allows mobile integration?
No, the MIF architecture hasn’t changed and it doesn’t look like it will in the near future. So the shortcomings are here to stay when it comes to mobile. Don’t get me wrong, it works, just not as well as you probably need it to.