08.01.08

MEA: XML and Flat files (Outbound)

Posted in Maximo at 1:18 am by Mike

The Maximo MEA has the ability to automatically generate both XML and flat files for outbound transactions. Out of the box, there is no way to automated the loading (inbound) of flat or XML files. Let’s look at how to do it.

Setup

The Integration Object and Integration Interface are setup as normal and you don’t need to do anything special for flat files or XML files. It is the External System where all the action is. Both XML and Flat files have there own End Points. There are no properties for the XML end point, but for the Flat Files you can specify the directory and the delimiter that separates each value.

This means, that for Flat Files, you can have multiple end points, each point to different folders. Of course the folder has to be accessible as a local drive on the server running Maximo. If you do not specify this directory, then the MEA will generate an error when it tries to write the files.  XML end point is a different story. Since there are no properties at the end point level, the only place to specify the folder is in the MEA Global Directory in the Integration Admin Setup.

The MEA will write the XML to a folder called “xmlfiles” under the directory specified here.

Once you specify your end point and setup the rest of the External System, you will need to add your outbound interface.

The last step is to enable the Integration Event for the interface. This is done by accessing the Enable/Disable Integration Events screen. If you created your own Outbound Interface, then there will automatically be an option here for it.

If you forget this step, then no matter how many changes you make to a record, it will never be passed into the MEA.

File Format

The XML file format is detailed my post MEA: XML Messages. Flat Files are a little different. The first line will have three values in it. The first is the name of the External System. Next comes the name of the Integration Interface. Last will the action (usually REPLACE). The next line will be the column names. The last line is the actual data. The data elements will be in the order of the column names.

   1:  MyExtSys,MXASSETInterface,Replace

   2:  ASSETNUM,PARENT,SERIALNUM,ASSETTAG,AS_LOCATION,AS_DESCRIPTION,VENDOR,FAILURECODE,AS_MANUFACTURER,PURCHASEPRICE,REPLACECOST,INSTALLDATE,WARRANTYEXPDATE,TOTALCOST,YTDCOST,BUDGETCOST,CALNUM,ISRUNNING,AS_ITEMNUM,UNCHARGEDCOST,TOTUNCHARGEDCOST,TOTDOWNTIME,AS_STATUSDATE,CHANGEDATE,CHANGEBY,EQ1,EQ2,EQ3,EQ4,EQ5,EQ6,EQ7,EQ8,EQ9,EQ10,EQ11,EQ12,EQ23,EQ24,PRIORITY,INVCOST,GLACCOUNT,ROTSUSPACCT,CHILDREN,BINNUM,DISABLED,AS_SOURCESYSID,AS_OWNERSYSID,AS_EXTERNALREFID,AS_SITEID,AS_ORGID,AUTOWOGEN,AS_ITEMSETID,AS_DESCRIPTION_LD,CONDITIONCODE,GROUPNAME,ASSETTYPE,USAGE,AS_STATUS,MAINTHIERCHY,ASSETID,MOVED,ASSETUID,TOOLRATE,ITEMTYPE,ANCESTOR,AS_SENDERSYSID,SHIFTNUM,TOOLCONTROLACCOUNT,PLUSDCREWID,N_ASSETREFID,NG_ELEVCOLUMN,NG_COORDINATE,NG_LOCATIONDESC,PLUSDFEATURECLASS,PLUSDISGIS,A,N_ASSETALIAS,N_ASSETGISID,N_BTU_APLY_IND,N_COMPNUM,N_DIALCOUNT,N_DMND_CNST,N_DTL_INDCR,N_DVVRF_CD,N_EQTYP_CD,N_FERCAT,N_FIX_FTR_VAL,N_FS_DMND_VAL,N_INDSTRBILL,N_MCE_PHS_CD,N_MODELNUM,N_MTRCF_CD,N_MTRSZ_CD,N_MTR_PCT_VAL,N_MTR_TYPE_CD,N_MULTYR_VAL,N_PRM_INDCR,N_PRSUR_INW_NUM,N_PRSUR_PSI_NUM,N_READINGREQ,N_RMVD_DT,N_RMVRSN_CD,N_SCMPRS_VAL,N_SEQ_NUM,N_UTIL_TYP_CD,N_XCOORD,N_XPCOORD,N_YCOORD,N_YPCOORD,N_ZCOORD,N_ZPCOORD,N_LEAKGRD,N_LOA,N_NISOURCEID,N_ORIGINCD,N_REMARKS,N_ITEMNUM,N_AMR,N_INDEX,TRANS_LANGCODE,METERNAME,ACTIVE,MEASUREUNITID,ROLLOVER,AVGCALCMETHOD,SLIDINGWINDOWSIZE,ROLLDOWNSOURCE,SINCELASTREPAIR,SINCELASTOVERHAUL,SINCELASTINSPEC,SINCEINSTALL,LIFETODATE,AM_CHANGEBY,AM_CHANGEDATE,REMARKS,AM_ORGID,LASTREADINGDATE,LASTREADING,POINTNUM,AVERAGE,READINGTYPE,LASTREADINSPECTOR,ASSETMETERID,PERSONID,AC_ORGID,ISUSER,ISCUSTODIAN,ASSETUSERCUSTID,ISPRIMARY

   3:  10000020026,10000020001P,,,16AAP0010,"BREAKER, EMERGENCY LUBE OIL PUMP 120V DC bubbles",,MOTOR,WEHS,0.0,0.0,,,0.0,0.0,0.0,,1,,0.0,0.0,0.0,2007-05-17T00:00:00-04:00,2008-07-31T20:52:22-04:00,MAXADMIN,,,,,,,,,,,,,,,,0.0,,,0,,0,,,,SGS,NIPSCO,0,,,,,ELECTRIC METER,,OPERATING,0,999999999974,0,999999999974,,,10000020001P,MX,,,,16A-APX-BKR-001046,0,,16A ELECTRICAL PACKAGE ROOM,,0,,,,0,,,,0,,,,,,1,,,,,,,,0,,,0,,,,,,,,,,,,,,,,,,,,EN,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

Although this doesn’t sound like a very powerful tool, you will find in development, the XML end point is one of the most useful. When you are setting up your Integration Object and Interface, you can use this end point to test it and get it right.

Permalink Comments

07.25.08

MEA: Web Service Part 3 - Outbound

Posted in Maximo at 3:56 pm by Mike

So far, we have covered how to get data into Maximo via a web service and how to query data out of Maximo. The last step is making Maximo push data out to a web service in another system. Let’s get started with the setup.

Integration Object and Integration Interface

I could write that you don’t have to do anything special when creating your Integration Object and Integration Interface and I technically would be correct. However, unless you are posting to another Maximo web service, nothing could be further from the truth. Remember in the Integration Interface, we can look at the Interface XML? Well, unless the target web service will accept that message format, they you have to do some work to get the message in the correct format. If possible, you can use Integration Objects screen to disable fields you don’t want to send, rename fields and even add field.  But if your web service is expecting a much different format (like without the header stuff), then you will have to create an Exit class (in java) for the end point to get the data in the correct format (more on where to specify this later).

External System

The first step is to create an external system for the web service. The name of the External System only matters if the other system receiving the message cares. (I am pushing to another Maximo system, so I called my External System ‘MX’).

Before you can specify an End Point, you must first create one for your target web service. To do this, select Add/Modify End Point from the Select Action menu.

From the Add/Modify End Point screen, click “Add New”. Give the end point a nice name (whatever you like) and for the Handler field, select Web Service. This will display a list of attributes in the bottom part of the screen. These are the properties and you need to specify them (note, there are two screens of them). Here is what they are (this is straight from the on-line help):

Property	Description	Required?
ENDPOINTURL	A valid Web service URL on which to invoke the document-literal style Web service.	Required
SERVICENAME	The name of the Web service specified in the URL.	Optional
TARGETNAMESPACE	The namespace of the Web service.	Required
USERNAME	User name for accessing the Web service.	Optional
PASSWORD	Password for accessing the Web service.	Optional
WSEXIT	Fully qualified name of the Java class that implements the WSExit interface.	Optional

WSEXIT is where you will specify your java class that will change the message format to what the web service needs.

Once you have entered all the values, click ok. Now you will be able to select the new end point for your External System. The last step on your External System is to add you Interface to the Outbound tab (oh, and don’t forget to enable it).

In my example, I did the standard MXASSET interface. so when I make a change in my Maximo to an Asset, the system will push that change to the external web service.

Although this seems relativity simple, there are a couple of “gotchas” you have to watch for.

1. The first I have already mentioned and that is the format of the message being sent. The the other system is Maximo, then this is not an issue, but for other systems, it will probably be an issue.
2. You have to create and External System and End Point for each external web service you want to post to. This could be a problem is the other application cares about that name. For non-Maximo applications, this is probably not an issue, but if the other system is Maximo, then this limitation will limit you to being able to post to one web service in the other Maximo. (To be honest, I have not tested this to see if there is a work around for it).
3. Error handling is tricky. Maximo will log any errors to the server log (like it does everything else) and it will keep trying to post the message. However, it does not write the error our to the MEA Globals folder. The message stays in the Message Queue until cleared or it is successfully posted.

Permalink Comments

07.22.08

The Joys of Business Travel

Posted in Humor at 9:07 pm by jeninalaska

#1- Smelly Travelers

Whenever possible, most of us will book a non-stop flight over a two-leg any day. As a business traveler from Alaska, I may do this more for the novelty of the non-stop than any other reason (hard to get in and out without a change over in Seattle / Salt Lake / Denver / Minneapolis – dependent on your choice of carrier). For the faithful, however, I have cooked up this precious pearl of wisdom that I believe you are worthy enough to appreciate. Don’t shun the two leg hopper. The hopper allows you an escape…. From the smelly traveler.

Case in point…

One – me, in this case - boards the always packed 8am flight from Anchorage to Seattle; flight time 3 hours 7 minutes. I settle in to my nice, cool window seat and make chit chat with the nice man behind me. (Note to self: It is clearly better to make friends with the person in front of you when flying coach. This is the person whom you want to remember your presence, preferably before they RECLINE all the way back and you can’t move, let alone bend over to get your computer case without contorting your person in ways that are normally reserved for prison escapees and hamsters.) Slowly, the plane begins to fill towards capacity. I have the happy delusion that the nice lady across the aisle of row 15 and I may be the only two fortunate people on this flight to own the row, as there has yet to appear an occupant for the dreaded middle seat. Then he shows up – minor heart sink, but I knew it was coming. The good news is he is not a large man. That is always an internal gasp… when the middle seat man shows up and you just know he will be bleeding over into your space, ensuring that you cannot move at all.

Anyway, the little guy sits down. He seems nice enough. He smiles. Opens up some engineering book and starts reading about the maximum load of bearings (did anyone else know you could calculate this with a three page equation?). And then it hits me. He is smelly. I wonder briefly where the odor is coming from. Surely, it cannot be from this young man, who seems only disheveled in that “college student forced to rise before 11am” manner. He yawns. The breath alone could have de-iced the wings of the airplane, but unfortunately I stood in its way. Yep, this one is smelly.

I’m wondering only briefly how I’m going to make it for three hours like this. Can I do one of those “SARS Mask” moves with my jacket? I have a mitten in my pocket! I could just breathe into that for three hours! Brilliant! Then it occurs to me that about a year ago I read an article on traveler’s health. Everyone is apparently concerned with being in tight, confined spaces like aircrafts for extended periods of time and being in such close proximity to the excess of germs that situation presents. This article stated that all aircrafts have air circulators that make the air cleaner than that of most office buildings. The air in a plane, it seems, is circulated no less than every 120 seconds. I pray for the freshness these circulators will soon bring to row 15.

Alas, after takeoff, and about 5 solid minutes of attempting to breathe into my shoulder, as I feel it would just look awkward to shove my nose down my own shirt for protection, the scent seems to dissipate slightly. Then the student decides it is time for his long overdue nap (he has, after all, read the big book of engineering from the time we pushed until we hit 20,000 feet, which takes, what, 6 whole minutes? He must be taxed!). He covers – yes covers – himself with a big thick jacket. I am ever grateful for this jacket as it appears to hold all of the smelliness back and away from my tender olfactory glands.

I give it a few minutes before I allow myself to begin thinking of all the work I have yet to complete. Since I almost have freedom of movement in my seat (save the aforementioned guy in front, whom I did not greet, who has reclined into my lap), I decide it is time to get out the old Dell and begin slaving away at the pursuit of knowledge exchange, aka the purpose of this business trip. I begin my classic contortionist move; drop left shoulder, pivot on hip, dip right arm between legs, begin to unzip (backpack, that is). I have to tell you this now, even though it is hard to type… as soon as I bend over, basically with my head between my own legs, someone (not me) drops their ass in such a severe manner I almost tear up. No, I did tear up. I still don’t know who it came from, but it had the distinct odor of “beer hangover”, so I’m crediting college boy. And that bugger lingered, I’ll tell you. Whoever timed those air exchangers on the two minute thing was horribly, terribly OFF when it comes to the air density of the beer hangover ass drop. That should be the air matter used for exchanger stress tests, I think, in the future. I may even try to find out who the manufacturer of these systems are so I can clue them in on the idea. Take your air exchanger to a college frat house. If it smells nice every two minutes, you’ve got a keeper.

So I tell you all of this information to make this point for all other business travelers… don’t shun the two legged hopper. As I was sitting in the terminal waiting on my connecting flight, delayed by a full hour and 45 minutes, I was STILL thankful that I could roll the dice for a shot at a non-smelly seat-mate. And indeed, American Airlines gave me a row all to myself. Which has to make me wonder… what is that STENCH. (tee hee)

Permalink 1 Comment

07.18.08

MEA: Behavior of Integration Objects

Posted in Maximo at 4:36 pm by Mike

It is important to under the behavior of Outbound Integration Objects. Specifically, I am talking about when data that is changed in the Maximo, what will trigger the Integration Interface.

When you create your Integration Object, you select a main MBO (this is the one without any parent MBO). For Outbound, this is the only object that will trigger the interface to send data. If you just modify the child records only, then the Interface will not fire. This is always the case, however there are cases where Maximo will act like the base object changed. This is a little confusing, so let us do a couple of examples.

Let’s say you have an Integration Object that has Asset as the base object and AssetSpec as the child object. Although if you were to only modify the AssetSpec MBO, then the interface would not fire, if you first open the Asset MBO and then grab the AssetSpec MBO from it and then modify it, it would fire. That is Maximo treats the child MBOs as as part of the base MBO. The Asset Screen is a great example of this in action. If you open an asset and then only change the AssetSpec tab data, the Interface will fire because Maximo treats a change to the child like a change to the parent.

However, if you were to create an Integration Object that liked WorkOrder (base) and Asset (child). Then, if via code, you were to open the WorkOrder MBO and then get the Asset MBO from that, it would work fine. But if you open the Asset Screen and modify the Asset, it will not fire.

This behavior is all well and good, but what if you needed it to fire whether you made changes to WorkOrder or Asset? Well, you can create a “Merged” integration object. With an Merged Integration object, Maximo will watch both tables and trigger on either. But it is not quite that simple. First, when you specify a merge object (and you have to check the box before you add your first MBO), you do NOT get to specify how the tables are related. The reason for this is that when a record is changed, the interface will only send the XML for that MBO and not of other MBOs in the Integration Object. So, back to our example of WorkOrder and Asset. If we made this a Merged Integration Object, then when an Asset was changed then the interface would send the XMl for just the ASSET MBO and none of the attributes would be present for WorkOrder. At the same time, if I added a user field to the WorkOrder MBO in the Integration Object, it also would not be present when Asset data is changed. On the other hand, if we were to make our Asset/AssetSpec a Merged Integration Object then when a user changes an AssetSpec from the Asset screen, Maximo will send two message, one with AssetSpec data and another with Asset data.  So, what if you need to send a message if either WorkOrder or Asset is changed and you need fields from both in the message (regardless of which MBO was changed)? What you have to do is in the Integration Object, for the WorkOrder MBO, add user fields for each field from Asset MBO that you need. And on the Asset MBO, add user field for each field from the WorkOrder MBO that you need. Then create a UserExit class that will populate the missing data for each (if WorkOrder was modified, then populate the Asset fields and if Asset was modified, then populate the WorkOrder fields).

Technorati Tags: Maximo Enterprise Adapter,Maximo,MEA,Integration Objects

Permalink Comments

07.11.08

MEA: Web Service Part 2 – Query/Response

Posted in Maximo at 2:23 am by Mike

In the last entry, we talked about the Notify Web Service. This is use for incoming “Syncing” data. If you want to get data out of Maximo (using a web service), then you have to setup a Query/Response web service. Basically, you can use one Integration Object (or two if you want the response to be different than the request), but you have to create two different Integration Interfaces.

Integration Objects

The fields you define in your Integration Object are the fields that you can query on and are the fields that will be returned from the Web Service. Although you can create two different integration objects (and their base MBOs need to be the same) to allow for one set of fields that can be queries and another that will be returned, it is most common to create just one Integration Object for both the Query and the Response. For our example, I will be setting up the MXAsset integration object.

The big difference between a standard “notify” web service and a Query/Response on are the end points. You have to create an inbound end point that has an operation of “Query” and an outbound end point that has an operation of “Response.”

Response Integration Interface

Next we have to create an interface for the response. The big difference is that the Operation is “Response” and the outbound integration point is the one from the Integration Object (you don’t select and inbound integration point).

Query Integration Interface

Now we create an interface for the Query (or request). Here the Operation is “Query” and you set the Inbound Integration Point. But you also fill out the Response Interface to your Response Integration Interface.

Now deploy this interface as a web service. You do NOT deploy the response interface, only the Query interface.

The last step is to add both interfaces to an external system. You have to add both the Query and Response interfaces and they have to be “Enabled.”

Calling the web service is the same as it was for Notify.

Samples

OK, now we have the web service setup, let’s see it work.  The first thing is creating a simple message. Here is an example of a simple asset query.

   1:  <?xml version="1.0" encoding="UTF-8"?>

   2:  <AssetQuery xmlns="http://www.mro.com/mx/integration" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="EN">

   3:    <Header operation="Query" event="0">

   4:      <RecipientID>MX</RecipientID>

   5:      <SenderID>EXTSYS1</SenderID>

   6:      <CreationDateTime>2008-07-10T06:41:55-06:00</CreationDateTime>

   7:    </Header>

   8:    <Content>

   9:      <ASSETQUERY>

  10:        <ASSET>

  11:          <ASSETNUM>26000</ASSETNUM>

  12:        </ASSET>

  13:      </ASSETQUERY>

  14:    </Content>

  15:  </AssetQuery>

Here we are asking for the Asset number 26000. Notice that even though there are many fields in the Integration Object, you only have to include the ones you are querying. Now we can use our favorite INTCLIENT.bat to test it.

The web service returned the data for Asset 26000. This works well if we just want one record returned, but you can get the system to return more than one record. Let’s talk about how that works.  In the example above, you notice that we didn’t tell the system how to do the compare. The default is actually do a “like.” For example if we did this query:

   1:  <?xml version="1.0" encoding="UTF-8"?>

   2:  <AssetQuery xmlns="http://www.mro.com/mx/integration" language="EN">

   3:    <Header operation="Query" >

   4:      <SenderID>EXTSYS1</SenderID>

   5:    </Header>

   6:    <Content>

   7:      <ASSETQUERY>

   8:        <ASSET>

   9:          <ASSETNUM>1004</ASSETNUM>

  10:        </ASSET>

  11:      </ASSETQUERY>

  12:    </Content>

  13:  </AssetQuery>

This would return all assets that had the value of “1004” in the AssetNum field. (The file was too big to insert.)

Asset-Like.XML XML Sample of returned data

Of course, this would suck if you just wanted the record for 1004. We can tell Maximo to do just an Equals by using the Operator attribute. This is how we would get just the record for 1004:

   1:  <?xml version="1.0" encoding="UTF-8"?>

   2:  <AssetQuery xmlns="http://www.mro.com/mx/integration" language="EN">

   3:    <Header operation="Query" >

   4:      <SenderID>EXTSYS1</SenderID>

   5:    </Header>

   6:    <Content>

   7:      <ASSETQUERY>

   8:        <ASSET>

   9:          <ASSETNUM OPERATOR="=">1004</ASSETNUM>

  10:        </ASSET>

  11:      </ASSETQUERY>

  12:    </Content>

  13:  </AssetQuery>

But there are lots of other operators too:

=	Equals
!=	not Equals
<	Less Than
<=	Less Than or Equal too
>	Greater Than
>=	Greater Than or Equal too

To check for a null value you can either use:

   1:  <ASSETQUERY>

   2:    <ASSET>

   3:      <SERIALNUM operator="NULL"></SERIALNUM>

   4:    </ASSET>

   5:  </ASSETQUERY>

or

   1:  <ASSETQUERY>

   2:    <ASSET>

   3:      <SERIALNUM>NULL</SERIALNUM>

   4:    </ASSET>

   5:  </ASSETQUERY>

You can use the Less/Greater than to do ranges. Do this you have to create two records in your request.

   1:  <ASSETQUERY>

   2:    <ASSET>

   3:      <YTDCOST operator="&gt;=">1000</YTDCOST>

   4:    </ASSET>

   5:    <ASSET>

   6:      <YTDCOST operator="&lt;=">10000</YTDCOST>

   7:    </ASSET>

   8:  </ASSETQUERY>

This example would return all assets that have a Year To Day Cost between 1,000 and 10,000.

You can also ask for a list of items. For example, say you want to return both Assets 26000 and 1004. Instead of doing two requests, you can do one like this:

   1:  <ASSETQUERY>

   2:    <ASSET>

   3:      <ASSETNUM>26000,1004</ASSETNUM>

   4:    </ASSET>

   5:  </ASSETQUERY>

If Maximo sees two (or more) items separated by a comma, then it does a “Like” query.

Well, this pretty much it for query/response web services.

Permalink 6 Comments

06.26.08

MEA: Web Service Part 1- Notify

Posted in Maximo at 8:52 pm by Mike

One of the features of the MEA is its ability to create a web service based on an integration interface. This is all done without having to write one line of code. You can create two different types of web services, Notify and Query/Response. A Notify web service is used for updating data. It is on inbound interface only. The web service will only return a “pass/fail” message. no data will be returned (like the ID it created for it). The other type, Query/Response is used for asking for data from Maximo. This will return one or more records of data, depending on what you ask for.  Let’s have a look at creating a Notify web service.

The first step is to make sure that you have the MEA configured properly. Now you create your Integration Object with and inbound Integration Point of type Notify.

Next you create the Integration Interface. Since Maximo creates the Web Service for you, you cannot add any custom processing to it. However, you can effectively accomplish this by adding inbound processing rules to the interface. After you save the Interface, but are still on the screen, select “Deploy as Web service” from the Select Action menu.

In this example I am deploying the MXItemInterface.

The last thing you must do is add the interface to an enabled external system as an inbound interface. Also make sure the interface in enabled on the External System.

Congratulations, you have deployed a web service. Here are the stats:

URL: http://servername:portnumber/meaweb/services/interfacename
Service name: interfacename
WSDL: http://servername:portnumber/meaweb/services/interfacename?WSDL
XSD: http://servername:portnumber/meaweb/services/interfacename.xsd

So in using Weblogic server and the MXITEMInterface interface, my values would look like this:

URL: http://mydomain.com:7001/meaweb/services/MXITEMInterface 
Service name: MXITEMInterface
WSDL: http://mydomain.com:7001/meaweb/services/MXITEMInterface?WSDL
XSD: http://mydomain.com:7001/meaweb/services/MXITEMInterface.xsd

To test it, you can use the INTCLIENT.bat tool. You will need to either create an xml file in the correct format (see integration interfaces on how to get the structure) or you can just export a record from the integration object to XML and then us it. Be sure to switch the sender and recipient IDs. Start up the INTCLIENT tool.

In the Client Type pull down, select SOAPDOC. Make sure the endpoint URL is correct as well as the service name. Click the BROWSE button and select your XML file you have ready. Now click test. The big text area will display the return message from the web service (including any errors).

Should an error occur, you would see the error message instead of "Success". The message will contain why Maximo rejected the message (invalid value, invalid date, etc).

On thing of note. If you do not change the Integration Web Application URL, then the WSDL will have issues. Web services uses this value when generating the WSDL and the XSD. If you do change it, then you will need to re-deploy any web service that you have already deployed.

This is standard web service and can be consumed by any language that can consume a web service.

Note for Java programmers. You can find the org.apache.soap library in %maximohome%/tools/maximo/soap.zip.  You can also find the JAXRPC.jar file in the %maximohome%/applications/maximo/lib folder.

Permalink 1 Comment

06.22.08

MEA errors fill log files

Posted in Maximo at 2:02 am by Mike

One thing you might find is that when you have a MEA record error, the JMS server keeps trying to reprocess the record over and over. This causes the server to slow down and fill up the drive space with log files. The reason for this is that the default setting is for the server to retry every message in the queue unlimited number of times and every second. I really don’t understand the logic of having a system retry a message that was in error, over and over again, without some user intervention first. However, this is easy to fix. These instructions are for Weblogic (I don’t have an instance of Websphere available to me so figure out how to fix it there).

Open the console for the Websphere and navigate to MyDomain->Services->JMS->Servers->[queue name]->Destinations->[destination name]   

Now click on the "redelivery" tab. The second text box, Redelivery Limit, is defaulted to -1. This means that the server will try infinitely to process the error. I am not sure what would be a good value for a production system (mainly because I can’t think of a situation where you would want the system to keep retrying records that are in error). For a development box, I recommend setting it to a value of 1. I also recommend doing this for all the queues.

Permalink Comments

MEA: Error Handling

Posted in Maximo at 1:59 am by Mike

When the MEA processes a record and it has an error, the MEA do three things. The first is that it writes the error message to the server log file. Next it sends the error to the administrators email address. The last thing is that it write an XML file to the MEA Global’s folder.

Lets have a look at these folders. The Error handling uses the Delete, DeletedHistory, Error and retry folders. Each of these directories will have a sub folder directory. The first level is the queue name. Under that will be a folder for each External System. When an error happens, it writes a message to the error folder. From here you can look at the message. Event though the message is written to this folder, it is still in the JMS queue. Deleting he message from this folder will NOT remove it from the queue. If you fix the error, you can move the message to the retry folder. If however you just want to delete the message from the processing queue, move the message to the delete folder. And messages that gets deleted will be copied to the DeletedHistory folder.

The load folder is used as the default for folder for loading flat file and XML files. Under this folder is a folder called "XML". This is where to put your XML or flat files to load. The other folder is called "backup" and the MEA makes backup copies of loaded files here.

The next folder is called "schema". When the MEA generates an XML schema, it writes it to this folder.

The last folder I am going to talk about is the XMLFiles folder. This is where applications like the INTCLIENT and VIEWQUEUE write their XML files too.

Permalink Comments

06.20.08

MEA: XML Messages

Posted in Maximo at 12:42 am by Mike

Let’s take a minute to look a the XML message format. When dealing with the MEA you will end up dealing with messages in XML format. Even when you import flat files and interface tables, Maximo converts each record to the XML format.

There are three different XML message formats, Integration Object, Integration Interface and Error Message. In reality, each builds on the prior message. Let’s start with the Integration Object.

Integration Object

This is where the actual data is formatted. In this example, we’ll look at MXItem Integration object.

   1:  <?xml version=”1.0″ encoding=”UTF-8″?>

   2:  <MXITEM xmlns=”http://www.mro.com/mx/integration”>

   3:    <ITEM>

   4:      <ITEMNUM />

   5:      <DESCRIPTION />

   6:      <ROTATING />

   7:      <LOTTYPE />

   8:      <CAPITALIZED />

   9:      <MSDSNUM />

  10:      <OUTSIDE />

  11:      <IN19 />

  12:      <IN20 />

  13:      <IN21 />

  14:      <IN22 />

  15:      <IN23 />

  16:      <SPAREPARTAUTOADD />

  17:      <INSPECTIONREQUIRED />

  18:      <SOURCESYSID />

  19:      <OWNERSYSID />

  20:      <EXTERNALREFID />

  21:      <IN24 />

  22:      <IN25 />

  23:      <IN26 />

  24:      <IN27 />

  25:      <SENDERSYSID />

  26:      <ITEMSETID />

  27:      <ORDERUNIT />

  28:      <ISSUEUNIT />

  29:      <DESCRIPTION_LONGDESCRIPTION />

  30:      <CONDITIONENABLED />

  31:      <GROUPNAME />

  32:      <METERNAME />

  33:      <COMMODITYGROUP />

  34:      <COMMODITY />

  35:      <ITEMTYPE />

  36:      <PRORATE />

  37:      <ITEMID />

  38:      <ISKIT />

  39:      <ATTACHONISSUE />

  40:      <TRANS_LANGCODE />

  41:      <CONVERSION>

  42:        <CONVERSIONID />

  43:        <FROMMEASUREUNIT />

  44:        <TOMEASUREUNIT />

  45:        <CONVERSION />

  46:        <CHANGEBY />

  47:        <CHANGEDATE />

  48:      </CONVERSION>

  49:      <ITEMCONDITION>

  50:        <CONDITIONCODE />

  51:        <DESCRIPTION />

  52:        <STOCKTYPE />

  53:        <CONDRATE />

  54:        <DESCRIPTION_LONGDESCRIPTION />

  55:        <COMMODITYGROUP />

  56:        <COMMODITY />

  57:        <ITEMCONDITIONID />

  58:      </ITEMCONDITION>

  59:    </ITEM>

  60:  </MXITEM>

The base tag (lines 2 and 60) are the name of the integration object. Next comes the main object (lines 3 and 59). Each attribute (field) in the MBO is a separate tag where the tag name is the attribute name. Remember that an Integration Object and consist of more than one MBO. In this example, Conversion and ItemCondition MBO are related MBOs. In the XML, you can see that Conversion (lines 41 thru 48) and ItemCondition (lines 49 thru 58) are where this data goes. Since the relationship between Item and these two MBOs is a Zero to Many, each of these sections will be repeated for each child record.

Integration Interface

An Integration Interface XML message wraps a few tags around the Integration Object XML message.

   1:  <?xml version=”1.0″ encoding=”UTF-8″?>

   2:  <MXITEMInterface xmlns=”http://www.mro.com/mx/integration” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” language=”EN”>

   3:    <Header operation=”Notify” event=”0″>

   4:      <RecipientID>EXTSYS1</RecipientID>

   5:      <SenderID type=”MAXIMO” majorversion=”6″ minorversion=”2″ build=”142″ dbbuild=”V600-502″>MX</SenderID>

   6:      <CreationDateTime>2008-06-19T14:32:47-06:00</CreationDateTime>

   7:    </Header>

   8:    <Content>

   9:      <MXITEM>

  10:        <ITEM>

  11:          <ITEMNUM />

  12:          <DESCRIPTION />

  13:          <ROTATING />

  14:          <LOTTYPE />

  15:          <CAPITALIZED />

  16:          <MSDSNUM />

  17:          <OUTSIDE />

  18:          <IN19 />

  19:          <IN20 />

  20:          <IN21 />

  21:          <IN22 />

  22:          <IN23 />

  23:          <SPAREPARTAUTOADD />

  24:          <INSPECTIONREQUIRED />

  25:          <SOURCESYSID />

  26:          <OWNERSYSID />

  27:          <EXTERNALREFID />

  28:          <IN24 />

  29:          <IN25 />

  30:          <IN26 />

  31:          <IN27 />

  32:          <SENDERSYSID />

  33:          <ITEMSETID />

  34:          <ORDERUNIT />

  35:          <ISSUEUNIT />

  36:          <DESCRIPTION_LONGDESCRIPTION />

  37:          <CONDITIONENABLED />

  38:          <GROUPNAME />

  39:          <METERNAME />

  40:          <COMMODITYGROUP />

  41:          <COMMODITY />

  42:          <ITEMTYPE />

  43:          <PRORATE />

  44:          <ITEMID />

  45:          <ISKIT />

  46:          <ATTACHONISSUE />

  47:          <TRANS_LANGCODE />

  48:          <CONVERSION>

  49:            <CONVERSIONID />

  50:            <FROMMEASUREUNIT />

  51:            <TOMEASUREUNIT />

  52:            <CONVERSION />

  53:            <CHANGEBY />

  54:            <CHANGEDATE />

  55:          </CONVERSION>

  56:          <ITEMCONDITION>

  57:            <CONDITIONCODE />

  58:            <DESCRIPTION />

  59:            <STOCKTYPE />

  60:            <CONDRATE />

  61:            <DESCRIPTION_LONGDESCRIPTION />

  62:            <COMMODITYGROUP />

  63:            <COMMODITY />

  64:            <ITEMCONDITIONID />

  65:          </ITEMCONDITION>

  66:        </ITEM>

  67:      </MXITEM>

  68:    </Content>

  69:  </MXITEMInterface>

The first thing to notice is the from line 8 thru line 67 is the Integration Object XML Message. Now the base tag is the name of the interface. The MEA uses this to route the message to the proper interface for processing. This message is now divided into two sections. A header (lines 3 thru 7) and the content (lines 8 thru 68). In this case, the content is just the Integration Object XML Message. The really important thing here is in the Header section. Line 3, the Header tag has one very important attribute: OPERATION. This tells Maximo or you what to do with the information in the message. For messages going into Maximo this will either be “Notify” (telling Maximo to update or sync the data) or “Query” (used to query Maximo data). For messages going out of Maximo this will be either “Notify” (telling the other system to sync or update the data) or “Response” (which is the results from the Query).

The next two lines (4 and 5) are very import to Maximo. The RecipientID is the name of the system that is receiving the message. For inbound messages, then needs to be “MX” (or whatever you have your MXSYSID setup as). For outbound, this will be the name of the External System the interface is attached to. The SenderID is the name of the system that is sending the message. For inbound, this MUST be the name of the External System the Interface is enabled on. For Outbound, this will be “MX” (or whatever you have your MXSYSID setup as). For a developer, the key to these two tags is that if you export a record, change it and want to send it back into Maximo to test your interface, then you just have to switch the values of these two tags.

The CreationDate tag (line 6) is optional.

Error Message

The last XML message is the format of the Error message that the MEA will generate. You will get one of these messages for each record that is in error.

   1:  <?xml version=”1.0″ encoding=”UTF-8″?>

   2:  <ERROR>

   3:    <ERRORMESSAGE>Error occurred while processing ITEM ( IR number 1, Integration Object number 1 ). Error is: Not a valid Yes or No value.</ERRORMESSAGE>

   4:    <ER>

   5:      <MXITEMInterface xmlns=”http://www.mro.com/mx/integration” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” language=”EN”>

   6:        <Header operation=”Notify” event=”0″>

   7:          <SenderID>EXTSYS1</SenderID>

   8:          <RecipientID>MX</RecipientID>

   9:          

  10:        </Header>

  11:        <Content>

  12:          <MXITEM>

  13:            <ITEM>

  14:              <ITEMNUM>6I-2500</ITEMNUM>

  15:              <DESCRIPTION langenabled=”1″>AIR FILTER -SECONDARY2</DESCRIPTION>

  16:              <ROTATING>0</ROTATING>

  17:              <LOTTYPE maxvalue=”NOLOT”>NOLOT</LOTTYPE>

  18:              <CAPITALIZED>2</CAPITALIZED>

  19:              <MSDSNUM />

  20:              <OUTSIDE>0</OUTSIDE>

  21:              <IN19 />

  22:              <IN20 />

  23:              <IN21 />

  24:              <IN22 xsi:nil=”true” />

  25:              <IN23 xsi:nil=”true” />

  26:              <SPAREPARTAUTOADD>1</SPAREPARTAUTOADD>

  27:              <INSPECTIONREQUIRED>0</INSPECTIONREQUIRED>

  28:              <SOURCESYSID />

  29:              <OWNERSYSID />

  30:              <EXTERNALREFID />

  31:              <IN24 />

  32:              <IN25 />

  33:              <IN26 />

  34:              <IN27 />

  35:              <SENDERSYSID>MX</SENDERSYSID>

  36:              <ITEMSETID>SET1</ITEMSETID>

  37:              <ORDERUNIT />

  38:              <ISSUEUNIT />

  39:              <DESCRIPTION_LONGDESCRIPTION langenabled=”1″ />

  40:              <CONDITIONENABLED>0</CONDITIONENABLED>

  41:              <GROUPNAME />

  42:              <METERNAME />

  43:              <COMMODITYGROUP>FILTERS</COMMODITYGROUP>

  44:              <COMMODITY />

  45:              <ITEMTYPE>ITEM</ITEMTYPE>

  46:              <PRORATE>0</PRORATE>

  47:              <ITEMID>228</ITEMID>

  48:              <ISKIT>0</ISKIT>

  49:              <ATTACHONISSUE>0</ATTACHONISSUE>

  50:              <TRANS_LANGCODE>EN</TRANS_LANGCODE>

  51:              

  52:            </ITEM>

  53:            

  54:          </MXITEM>

  55:          

  56:        </Content>

  57:        

  58:      </MXITEMInterface>

  59:    </ER>

  60:    <IR>

  61:      <MXITEMIN xmlns=”http://www.mro.com/mx/integration” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” language=”EN”>

  62:        <Header operation=”Notify” event=”0″>

  63:          <SenderID>EXTSYS1</SenderID>

  64:          <RecipientID>MX</RecipientID>

  65:          

  66:        </Header>

  67:        <Content>

  68:          <MXITEM>

  69:            <ITEM>

  70:              <ITEMNUM>6I-2500</ITEMNUM>

  71:              <DESCRIPTION langenabled=”1″>AIR FILTER -SECONDARY2</DESCRIPTION>

  72:              <ROTATING>0</ROTATING>

  73:              <LOTTYPE maxvalue=”NOLOT”>NOLOT</LOTTYPE>

  74:              <CAPITALIZED>2</CAPITALIZED>

  75:              <MSDSNUM />

  76:              <OUTSIDE>0</OUTSIDE>

  77:              <IN19 />

  78:              <IN20 />

  79:              <IN21 />

  80:              <IN22 xsi:nil=”true” />

  81:              <IN23 xsi:nil=”true” />

  82:              <SPAREPARTAUTOADD>1</SPAREPARTAUTOADD>

  83:              <INSPECTIONREQUIRED>0</INSPECTIONREQUIRED>

  84:              <SOURCESYSID />

  85:              <OWNERSYSID />

  86:              <EXTERNALREFID />

  87:              <IN24 />

  88:              <IN25 />

  89:              <IN26 />

  90:              <IN27 />

  91:              <SENDERSYSID>MX</SENDERSYSID>

  92:              <ITEMSETID>SET1</ITEMSETID>

  93:              <ORDERUNIT />

  94:              <ISSUEUNIT />

  95:              <DESCRIPTION_LONGDESCRIPTION langenabled=”1″ />

  96:              <CONDITIONENABLED>0</CONDITIONENABLED>

  97:              <GROUPNAME />

  98:              <METERNAME />

  99:              <COMMODITYGROUP>FILTERS</COMMODITYGROUP>

 100:              <COMMODITY />

 101:              <ITEMTYPE>ITEM</ITEMTYPE>

 102:              <PRORATE>0</PRORATE>

 103:              <ITEMID>228</ITEMID>

 104:              <ISKIT>0</ISKIT>

 105:              <ATTACHONISSUE>0</ATTACHONISSUE>

 106:              <TRANS_LANGCODE>EN</TRANS_LANGCODE>

 107:              

 108:            </ITEM>

 109:            

 110:          </MXITEM>

 111:          

 112:        </Content>

 113:        

 114:      </MXITEMIN>

 115:    </IR>

 116:  </ERROR>

 117:   

The base tag is an ERROR tag. Line 3 is the error message that was generated. If you look close you will see that the Interface message in here twice in the message. The first is from line 6 thru line 58 and is encased by an ER tag while the second from line 1 thru 114 is encased in an IR tag. Basically, the IR section is the original incoming message (record) while the ER section is the message that cause the error. In this example they are the same, but if you have any processing rules or custom exit class that changes the data, then this will be what the data looked like after those changes were made.

Permalink Comments

06.18.08

You Might be a "geek" if…

Posted in Humor at 5:47 pm by Mike

I found this posted at :http://geekswithblogs.net/KirstinJ/archive/2008/06/17/you-may-be-a-geek-if.aspx but liked it so much I just had to re-post it here. Full credit belongs to “I [heart] TFS” blog for the list. BTW: I found the Google one more scary than funny…

• You know that Fibonacci is not a fine wine or type of bread.
• Your Christmas list is a color-coded spreadsheet with sort capabilities on person, store, and price.
• The last party you attended was a slide deck check.
• Your MP3 player contains more .NET podcasts than music.
• The average shelf life of the books you purchase is 3 months.
• You have more email addresses than you have digits in your phone number.
• That’s ok, because you have linked them all together with single sign-on from your smart phone.
• You think that Facebook and MySpace are so-o-o 2007.
• You know more people by their twitter handle than by their real names.
• You can’t multitask worth @%&@ in the real world, but you can handle a debugging session, a SQL window, three IM windows, and a twitter client simultaneously.
• If Google went down, your productivity would plummet.
• When you hear the acronym “MVP” you don’t think “Most Valuable Player”.
• When you hear “waterfall”, you don’t think of Niagara, and you need to restrain yourself from running away screaming.
• When your boss asks you “When was the last time you worked with COM?”, he doesn’t mean communications, and you do run away screaming.
• A night of drinking involves everyone consulting their GPS before proceeding to the next venue.
• A night of drinking ends up at the office where everyone can fire up their laptops and swap MP3 files.
• When you’re feeling old, you give your age in base-11.
• You divide the world into 10 types of people - the ones that understand binary, and the ones that don’t.
• You laughed at at least half the items on this list.