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.

https://www2.gotomeeting.com/register/849468586

Al Johnson
VP Product Development
Total Resource Management
al.johnson@trmnet.com

https://www2.gotomeeting.com/register/849468586

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?

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

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.

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.

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.

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.