Load Balancer Maximo Consultant's Blog

Just a bunch of my personal notes about Maximo attachment (DOCLINKS)

When a file is attached to a record in Maximo, it creates a record in the DOCLINKS and a record in the DOCINFO table to keep the details of the file. The file is copied to a location on disk, usually on a local folder (e.g. D:DOCLINKS) or on a shared network folder. The path for Maximo to read the file is kept in the URLNAME field of the DOCINFO table.
To set up this function, refer to this blog post by Bruno
When a user uploads an attachment, the location where Maximo puts the file will depend on the Folder selected:

In most applications such as Work Order Tracking or Assets, there is a Select Action > Attachment Library/Folders > Manage Folder function, it allows you to specify the location to keep the file for each Folder.

If no path is specified for a folder, Maximo uses the default value of the System Properties: mxe.doclink.doctypes.defpath

This setting controls where to keep the file when uploading. After a migration or upgrade in which you moved your file server location, and if new files still end up in the old location. This is where you should update your settings
When a user clicks on the link to download an attachment, there are two methods for Maximo to serve the file.

If System Property: mxe.doclink.securedAttachment is set to False (default), the HTTP Web Server will read the file from disk, then serve it to the end-users. Maximo application server doesn’t play a role in delivering the file here.

If System Property: mxe.doclink.securedAttachment is set to True, when the end-user downloads an attachment, Maximo application server will grab the file, encrypt it, then serve it to the end-user. Thus, in this case, we don’t really need the web server for it to work. I.e. if you accessing Maximo directly on the application server (via port
908x), it will still work. Thus, in a clustered environment in which a load balancer distributes load directly to Maximo JVMs without a web server in the middle, this is the recommended choice.
The link to download an attachment is kept in DOCINFO.WEBURL non-persistent field. The value of this field is generated by replacing the URLNAME field of the DOCINFO record, with the rule set in the mxe.doclink.pathXX property.
For example, if you have the following rule: mxe.doclink.path01=D:DOCLINKS=https://maximo.company.com/attachments/ For a document with URLNAME=D:DOCLINKSdrawingfile01.pdf, the WEBURL would be https://maximo.company.com/attachments/drawing/file01.pdf. If the first part of URLNAME doesn’t match with the left-side of the PATH01 equation, Maximo will look at mxe.doclink.path02,path03 and so on to replace the value and generate a WEBURL. If there’s no match, it will generate WEBURL with an absolute path: file://[URLNAME]. This means that if the user has access to the file on the shared network path, it will still work without the need for a web server.

In summary, I usually hit with issues with doclinks after an upgrade or migration, I use the following checklist to avoid those issues:

If a new Web server is set up, need to update the DocumentRoot, and the Directory settings in the web server’s httpd.conf file
If the Web URL to access Maximo changes: need to update mxe.doclink.path01
If the file server location was moved:
- Need to copy the file to the new location
- Maximo service account should have permission to access the local/network folder
- Update:
  - mxe.doclink.doctypes.topLevelPaths
  - mxe.doclink.doctypes.defpath
  - mxe.doclink.path01
- Update the DOCTYPES.DEFAULTFILEPATH in
  the database with a REPLACE SQL command
- Update all DOCINFO.URLNAME in the database with a REPLACE SQL command

Property mxe.system.useLoadBalancer

This setting should be set to 1. If not enabled, Maximo thinks the IP address of the Load Balancer’s IP is the client’s and blocks it when the number of requests exceeds a certain threshold (by default is 50 per 3 seconds). For more details about the IP blocking function, refer to this previous post Maximo 7.6. feature – Denial of Service attack

Load Balancer session timeout

I recently worked with a client who set up Citrix NetScaler as the LB for Maximo. Its default session timeout is 2 minutes. A load balancer (LB) should have session stickiness, meaning it should keep forwarding all requests from one user to the same Maximo application server throughout the whole user’s session. When the LB session times out while Maximo session is still active, a new request from the same user will be directed to a new application server that doesn’t manage the current active Maximo session, it forces the user back to the login screen.

To fix this, we need to increase the LB session timeout to be more than the timeout setting in Maximo (by default, it’s 30 minutes).

Please note: if you have LDAP integration, the LTPA token is a different login session maintained by Websphere and is not related to this. LTPA token will expire after a fixed duration from logging in regardless of whether the user is active or not. This caused the users to be randomly logged out. Thus, I usually set LTPA token timeout to a very high value (e.g. 10-15 hours)

Property mxe.int.webappurl

if Maximo is only accessible via the LB’s URL, we should update the few webappurl properties pointing to that URL. If the URL values set there are wrong, it leads to an incorrect URL returned in the integration responses. This in turn can lead to error BMXAA5798E when deploying Web Services or generating XML schemas. We can set the mxe.int.verifywebappurl to 0 to avoid the issue when generating XML Schema

Websphere rewriting port 80/443 to application server ports 9080/9443

If the Load Balancer is set up to distribute load directly to the application servers
without the HTTP Webserver sitting in between, you can get this issue. To fix this, for each application server (JVM), add two Web Container custom properties below and set them to True:

com.ibm.ws.webcontainer.extractHostHeaderPort

Trusthostheaderport

Missing integration message due to Load Balancer’s Maintenance Page

During the maintenance window of the external application’s servers (e.g. software patching), if Load Balancer is set to display a maintenance page, and the HTTP Response Status Code of the page is 2xx, any integration message Maximo sent to the server via the LB shall be marked as successful while the target system never receives them. This can cause missing data in the target system. Refer to this post for more details: The curious case of the MIA work orders

Category: Load Balancer

Issues with Maximo attachment (DOCLINKS)

Recent Posts