MBO Date Formats

Sometimes we need to filter the MboSet records based on dates.

• By using MXFormat.dateToSQLString(Date d) you can get the date format as "yyyy-MM-dd".

For example:
MboSetRemote mboSetRemote = getMboSet("ASSET");
mboSetRemote.setWhere(MXFormat.dateToSQLString(getDate("STATUSDATE")));

Here MXFormat.dateToSQLString will return date as string and format is '2015-09-17' (with single quotes).

• If your database is using different date format, then update it in system properties mxe.db.format.date and use SQLFormat.getDateFunction(Date d)

For example:
MboSetRemote mboSetRemote = getMboSet("ASSET");
mboSetRemote.setWhere(SQLFormat.getDateFunction(getDate("STATUSDATE"));

Here SQLFormat.getDateFunction will return date as string in two ways:

1. If mxe.db.format.date is not null/blank then it will return string with given date format in this property.
for example: If mxe.db.format.date is dd-MM-yyyy, then return string will be '17-09-2015' (with single quotes)
2. If mxe.db.format.date is null/blank, then it will return same as MXFormat.dateToSQLString method, i.e. '2015-09-17' (with single quotes).

Hope it helps :)

BMXAA6002E - You cannot save object JOBPLAN : Job Plan=TESTJP1 Organization=ORG1 Site=SITE1 Revision=0 because of the data security restrictions. If you save the object, it becomes read-only and hidden

Error: BMXAA6002E - You cannot save object JOBPLAN : Job Plan=TESTJP1 Organization=ORG1 Site=SITE1 Revision=0 because of the data security restrictions. If you save the object, it becomes read-only and hidden

Environment: Maximo 7.6.0.1

Steps to reproduce above error:

1. Create a job plan and save it with DRAFT status.
2. Create a condition expression "status <> 'DRAFT'".
3. Create a global data restriction --> Object restriction --> Object JOBPLAN , app JOBPLAN , READONLY and add condition created in step 2.
4. Create a new user and associate a security group which has access job plan application (not maxadmin group).
5. Login with new user and go to job plans application.
6. Change status of job plan created in step 1 to ACTIVE and save the record.
7. Above error will occur.

Note: These steps will reproduce error in Maximo 7.6.0.1. In Maximo 7.1, job plans are editable even status is ACTIVE. So above steps will not reproduce errors in Maximo 7.1.

Cause: Out of box Job plan mbo is flagged to readonly when status is ACTIVE or INACTIVE. In our case, condition again trying to flag it readonly for the same mbo, hence this error occurs.

Solution: No need to put condition for Job plan to make it READONLY when status is ACTIVE or INACTIVE.

These are just my findings, if anyone have different approach, please provide your inputs in comments.

Maximo restore database error in SQL Server

System.Data.SqlClient.SqlError: RESTORE cannot process database '<DbName>' because it is in use by this session. It is recommended that the master database be used when performing this operation.

While restoring database, faced above issue.

Even though all services stopped, still restore database given error that “Database is in use by this session”

Solution:

Connect to Sql server management studio:

Expand Security à Login à Right click on “maximo” à Click Properties

 “Default database:” value = <your database name>. Change it to “master”.

Automation Script - Retrieve List

Sample code - Retrieve list event of attribute launch point in automation script:

In my example, I want to display only PR companies starting with "SK".

1. Created a table domain, TEST_COMP_SK
2. Create a attribute launch point and select option "Retrieve List".

Launch point name: TEST_PRVENDOR
Object: PR
Attribute: VENDOR

Script Name: TEST_RETRIEVELIST
Script Language: jython

Source Code:

domainid = "TEST_COMP_SK"
listWhere = "COMPANY LIKE 'SK%'"
listOrder = "COMPANY"

Save the script.

THATS IT :)

Now you can test in PR application - Company lookup - It will display companies starting with SK and order by company name ascending.

Below information will give the list of implicit variables in Retrieve List event:

1. domainid - Specifies the domain that is used to provide the list of values that are shown for the attribute launch point.
2. listWhere - Establishes which set of result data is displayed and which filter is set before the results are shown. Set the listWhere variable to a WHERE clause that uses the related MBO.
3. listOrder - Set to any ORDER BY attribute names that are used to order the results of the retrieve list event.
4. relationObject - Applies to the related MBO that is searched from the current MBO.
5. relationWhere - Establishes the criteria that is used to perform the retrieve list event. Set to a WHERE clause that queries the related MBO.
6. srcKeys - Applies to the set of attribute names from the current MBO that is used to lookup a related record in another related or target MBO. For example, the set of attribute names from the current MBO might be used to look up that FAILURECODES field from the ASSET business object.
7. targetKeys - Applies to the set of attribute names in the target MBO that is looked up from the current MBO on which the attribute launch point is defined.
8. listErrorGroup - Identifies the group ID of the message that the user sees when the retrieve list event fails.
9. listErrorKey - Identifies the key ID of the message that the user sees when the retrieve list event fails.

Source: http://www-01.ibm.com/support/knowledgecenter/SSLKT6_7.6.0/com.ibm.mbs.doc/autoscript/r_variables_automation_scripts.html?lang=en



 

Error: The mbo value info for atttribute AUTHALLGLS for object grpreassignauth could not be retrieved

One of my friend faced this issue. This error is little bit tricky, because there is no attribute called "AUTHALLGLS" exist in GRPREASSIGNAUTH table. But still maximo throws this error. And also error logs will not provide any detailed information. This error can find in system out log as a warning.

This error can occur while creating new security group or assigning security group to user.

Cause: Few security groups has granted access to create users.

Solution: Except for MAXADMIN security group, need to remove granted access to create users for other security groups.

I am providing this in my blog, just in case, if anyone faces this issue and not to waste their time to solve it.

 

Continous queue stopped processing records into queue.

While importing records into Maximo using continuous queue, after certain amount of errors (in my case, after every 10 errors) in message reprocessing application, continuous queue stopped working.

To solve this issue, I followed below steps:

1. Enable MDB bean for cqin err:

Take a backup of "ejb-jar.xml" from "<Drive>:\IBM\SMP\maximo\applications\maximo\mboejb\ejbmodule\META-INF"
Open the file from "ejb-jar.xml" in notepad++, search for "MEA MDB for error queue". Uncomment it.

BEFORE CHANGE:

<!-- MEA MDB for error queue
    <container-transaction>
     <method>
        <ejb-name>JMSContQueueProcessor-2</ejb-name>
        <method-name>*</method-name>
     </method>
   
     <trans-attribute>Required</trans-attribute>
   
    </container-transaction>
-->

AFTER CHANGE:

<!-- MEA MDB for error queue-->
    <container-transaction>
     <method>
        <ejb-name>JMSContQueueProcessor-2</ejb-name>
        <method-name>*</method-name>
     </method>
   
     <trans-attribute>Required</trans-attribute>
   
    </container-transaction>

Take a backup of "ibm-ejb-jar-bnd.xmi" from "<Drive>:\IBM\SMP\maximo\applications\maximo\mboejb\ejbmodule\META-INF"
Open the file from "ibm-ejb-jar-bnd.xmi" in notepad++, search for "MEA MDB for error queue". Uncomment it.

BEFORE CHANGE:
<!-- MEA MDB for error queue
  <ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1" activationSpecJndiName="intjmsacterr">
    <enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#MessageDriven_JMSContQueueProcessor_2"/>
  </ejbBindings>
-->
AFTER CHANGE:
<!-- MEA MDB for error queue-->
  <ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1" activationSpecJndiName="intjmsacterr">
    <enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#MessageDriven_JMSContQueueProcessor_2"/>
  </ejbBindings>

Rebuild and Redeploy maximo.

2. Login into Maximo:

Go to --> System Configuration--> Platform Configuration --> Select "Crontask setup" --> Search for "JMSQSEQCONSUMER" and open it.

Create a crontask instance of "CQINERR", Schedule "30s,*,*,*,*,*,*,*,*,*", Runas user "MAXADMIN".
 In parameters, Enter below values:
MESSAGEPROCESSOR = psdi.iface.jms.QueueToMaximoProcessor
QUEUENAME = psdi.iface.jms.QueueToMaximoProcessor
ERRORQUEUE = 0
TARGETENABLED = 0

Activate the instance and save the crontask.

3. Change destination of errors in websphere:
Login into websphere.
In Left panel --> Expand "Service Integration" --> Click on "Buses" --> Right panel click on "intjmsbus"-->Under "Destination Resources" click on "Destinations" -->Click on CQINBD -->Under "Exception Destination" select "Specify"--> Enter the value CQINERRBD --> Click "Apply" --> Save it into master --> Click ok --> Save it into Master.
Note: No need to restart server.

Testing:

Import 100 error records into any application and search in message processing that all 100 records exists in it. Earlier it was only 10 error records in my case, now it shows all 100 records.
In websphere, you can notice that all error records are moved into cqinerrbd destination.

I hope this article may help to some one who are new to maximo websphere process. As I suggest always, first try in development environments and also above mentioned parameters may differ based on environments.




 

BMXAA0667E - The value of the changed attribute could not be assigned.

Error: BMXAA0667E - The value of the changed attribute could not be assigned.


 I faced this error, when trying to update length of one field in INVENTORY table. The field which I am trying to update length is a same as object and same as attribute in INVVENDOR table. So I started investigating INVVENDOR table, then I found below cause.

In my environment, problem is, INVVENDOR has a audit table A_INVVENDOR, but audit enabled is unchecked.
While investigating, found that, audit table A_INVVENDOR details available in MAXATTRIBUTECFG and MAXATTRIBUTE tables, but A_INVVENDOR table itself not exist.

Note: Before doing below changes, make sure you have backup of database. And better try in your development environment first.

Steps:

1. In database configuration, INVVENDOR table, make sure audit is disabled and audit table field is blank. In my case, audit enabled is false, but audit table field has value A_INVVENDOR. To remove, audit table field (it is read only), first check the check box of audit enabled, it makes audit table field editable. Now remove value of audit table field and uncheck audit enabled field. Save the record.

2. Apply configuration changes. It will remove A_INVVENDOR meta data available in MAXATTRIBUTECFG and MAXATTRIBUTE tables.

3. Now, change the length of the required field in INVENTORY table and save the record. Error will not occur.