Web Services Issues after Maximo upgrade from 7.1 to Maximo7.6.0.8

Issue: Web services issues after upgrade From 7.1 to 7.6

Solution:-

1.     Delete all the web services from Maximo

2.     Recreate all the web services and Re generate the XML

3.     Check in the browsers

            Ex: http://serverhost:portnmber/meaweb/services/web servicename?wsdl

4.     Add the new property in Web sphere server

Application servers > MXInt_Cluster_01 > Process definition > Java Virtual Machine > Custom properties

            Property Name: webservices.unify.faults

Value : false  

5.     Check the below System Properties in Maximo

mxe.int.resolveschema =1

6.     Test the Web services

Using conditional expressions for classifications

Prevent users from selecting some classifications but you cannot delete the classifications

• Description: As part of the implementation process, one of the tasks a customer completes is creation of the classification hierarchy. When classifications that made sense when you went through implementation no longer make sense, what can you do? You might delete the classifications that are not applicable. But if those classifications have been associated with item, you cannot delete them. You could also tell your users not to use the classifications or find every ticket that the classifications were applied to and delete them from the ticket. But both solutions have problems either from a usability perspective or from a data integrity perspective.

• Issue: You cannot delete a classification when it has been used in applied to an item.

• Solution overview: Use the configuration tools to enable an object restriction-based solution to hide the designated classifications from users, effectively preventing users from selecting them.

Solution

There are two parts to the solution because there are two fields in the application that are available for looking up classifications.

• Hierarchical lookup is available from the Detail menu on the Classstructure.Hierarchypath field. Restrict the lookup at the highest level you wish to hide, and everything below in the hierarchy is hidden.
• A Select Value item is available from the Classstructure.Description_Class You must restrict the individual classifications.
  
  
  
  

Restrict the lookup

In this example, classifications that are marked with the HIDE attribute (:hide=1) are not displayed to any agents of the Service Desk Rep (Tier 1) Service Group.

1. In the Database Configuration application, add a YORN attribute called HIDE to the Classstructure record. This attribute will be used to specify the classifications to hide from the user.
2. In the Application Designer, open the Classifications application.
3. Add the HIDE attribute to the application.
   
4. In the Conditional Expression Manager, create the expression :HIDE=0. For information about building conditional expressions, see the Conditional Expression Manager online help.
   
5. Open the Security Groups application.
   • Create a security group called SDRep1 to add users to that group.
     Or
   • Add an object restriction to an existing group to restrict all users in that group.
6. On the Data Restrictions tab, select the Object Restrictions tab.
7. In the Object field, specify the Classstructure object.
8. In the Condition field, click Detail menu and choose Select Value to select the expression :Hide=0.
   

Hide a classification

In this example, Hide is selected for the top-level classification "End User Issues".

Results

The results differ depending on the type of lookup from the field.

• From the Classification field, all classifications below the hidden classification are hidden.
• From The Class Description field, only the hidden classification is hidden.

You can synchronize these fields in two ways:

• Select Hide for all the classifications in the hierarchy.
• Remove the lookup from the Class Description field.
   

Classification Field Hierarchical Lookup - Nothing below the hidden classification is available

Class Description Field - Only the hidden classification is not available. Any child classification with the terms "END USER" are still available.

---

Filter items by classification at a more granular level than at the application level

• Description: Acme Service Desk distributes their incoming tickets based upon the initial classification selected by the self-service user. The default ownergroup for that classification is assigned to the ticket, when the classification is selected by the user. Ownergroup A is assigned to any ticket that has a classification that begins with a 1, 2, or 3. Ownergroup B is assigned to any ticket that has a classification that begins with a 4, 5, or 6. When agents of the service desk in ownergroup A log in, they see all tickets currently assigned to them and to any group they belong to. They select a service request and begin working on it. Part of their work is to validate that the proper classification was used and the appropriate level of classification was selected. When evaluating the classification, the agents are presented not only with the classifications they are assigned to (those beginning with 1, 2, or 3), but also the classifications that are the responsibility of ownergroup B. What do you do when you want the agents to see tickets only with the classifications their group is responsible for?

• Issue: The classification Use with flags are at the application level. You require a more granular solution.

• Solution overview: Filter the classification presentation based on security group ownership by setting a restriction.

Solution

Create a security group with a defined Object Restriction for the Classstructure object. Create a conditional expression to present certain nodes of the Classstructure object, based upon classificationid. Finally, we associate the user's record to the new Security Group.

This example restricts Sinclair from seeing classification nodes other than 1 and 2. Before the change, Sinclair has access to all incident-related classifications.

Create the restriction

1. Open the Security Groups application.
2. Create a security group called Class1and2.
3. On the Data Restrictions tab, select the Object Restrictions tab.
4. In the Object field, specify Classstructure.
5. In the Condition field, click Detail Menu and specify an expression that shows Classifications that start only with 1 or 2.
   For example, :classificationid like '1%' or classificationid like '2%'

   Tip Make the restriction expression as specific as you need to support which groups need to see which classifications.

6. Add the user Sinclair to the group.
7. In the Conditional Expression Manager, create an expression that matches the Object Restriction you created.
   For information about building conditional expressions, see the Conditional Expression Manager online help.
    

Test the restriction

1. Log in as Sinclair
2. From the Incidents application, create an incident
3. In the classification field, select Classify. Only Classification nodes 1 and 2 are available.

Removing temporary data : -When installing Maximo Base Services 7.5 or Base Services Fixpack 7.1 you get an error: CTGIN2489E.

Removing temporary data

If you have modified the Maximo database since you installed another product or component, make sure all of your changes are completed before you begin a new upgrade or installation procedure.

All changes must be committed to the database before you can upgrade an existing product or install a new product or component. Tables whose names begin with "XX" are temporary tables that must be dropped before installing. If these tables exist, you will see error CTGIN2489E when you run an upgrade or installation procedure.

Temporary data can exist in your database in these situations:

• You are upgrading an existing product after configuring and using it.
• You are installing a new product or component in an environment where you have already installed another product, and configured and used that product.
• You are using the installer to add a feature or function that you did not implement when you first installed your product.

If you are in one of these situations, check whether you have any uncommitted changes or temporary tables in your database.

1. To confirm that all changes have been committed, run the following SQL query against the Maximo database:

   SELECT count(*) from maxobjectcfg where changed != 'N'

   'N' indicates that a change has been committed. For this query, if entries are returned with a value of 0 instead of N, you must commit those changes. Follow these steps to commit the changes:
   1. Click Go To > System Configuration > Platform Configuration > Database Configuration.
   2. From the Select Action menu, click Manage Admin Mode.
   3. Click Turn Admin Mode ON.
   4. Click OK, then wait for a few minutes for the change to take effect.
   5. From the Select Action menu, click Apply Configuration Changes. Monitor the process to completion.
   6. From the Select Action menu, click Manage Admin Mode.
   7. Click Turn Admin Mode OFF.
   8. Stop the MXServer.
   9. On the administrative Workstation, open a command prompt. Change to the directory c:\ibm\smp\maximo\tools\maximo.
   10. Run the following commands:

       configdb.bat
       dropbackup.bat
       dropbackup.bat

       The dropbackup.bat command is run twice. This should complete the commitment of all database changes.
2. Determine whether any temporary tables exist in your database, using the command appropriate to your database:

   DB2®

   select count(*) from sysibm.systables where name like 'XX%' and 
   creator = 'MAXIMO'

   Microsoft SQL Server

   SELECT count(*) FROM sysobjects WHERE xtype = 'U' AND name like 'XX%'

   Oracle

   SELECT count(*) from all_tables where table_name like 'XX%'

   If the returned value is not 0, follow these steps to drop the temporary tables:
   1. On the administrative Workstation, open a command prompt. Change to the directory c:\ibm\smp\maximo\tools\maximo.
   2. Run the following commands:

      configdb.bat
      restorefrombackup.bat
      dropbackup.bat
      dropbackup.bat 

      The dropbackup.bat command is run twice. This should drop all the temporary tables in the database.

Now you can proceed with your upgrade or installation procedure.

Integrity Checker reports BMXAA0494E errors on table COMMLOG.

Problem

After upgrading a Maximo 6.2 database to 7.1, several columns on table COMMLOG do not match the way that the columns are defined in Maximo.

Issue

In Integrity Checker report:
BMXAA0443E -- ERROR -- BMXAA0494E -- The Maximo definition of this column does not match the actual column:
BMXAA6841I - COMMLOG.BCC, Maximo definition is CLOB, Database column is VARCHAR2(4000)
BMXAA0443E -- ERROR -- BMXAA0494E -- The Maximo definition of this column does not match the actual column:
BMXAA6841I - COMMLOG.CC, Maximo definition is CLOB, Database column is VARCHAR2(4000)
BMXAA0443E -- ERROR -- BMXAA0494E -- The Maximo definition of this column does not match the actual column:
BMXAA6841I - COMMLOG.SENDTO, Maximo definition is CLOB, Database column is VARCHAR2(4000)

Resolving the problem

1. For each column, add to table COMMLOG a new column with data type CLOB. For example:
Alter Table commlog Add bccnew CLOB;
2. Copy the original column to the new column. For example:
Update commlog Set bccnew = bcc ;
3. Drop the original column. For example:
Alter Table commlog Drop Column bcc ;
4. Rename the new column to the original name. For example:
Alter Table commlog Rename Column bccnew To bcc ;
5. Run Integrity Checker again to verify that the errors are no longer reported.

Upgrade to Maximo 7.5 fails in UpdateDB script V7500_343.

Problem(Abstract)

When upgrading the Maximo database to 7.5.0.x, UpdateDB can fail in script V7500_343.dbc:


BMXAA7025E -- Script failed while running.;

A statement failed to execute inside a freeform statement;

sql#1407;
ORA-01407: cannot update ("INVENTORY"."COSTTYPE") to NULL

-- BEGINUPDATEDBERROR

-- Product: Tivoli's process automation engine
-- Error running file: V7500_343
-- UPDATEDBFILE:V7500_343.dbc

Symptom

The V7500_343 freeform statement that fails is:

update inventory set inventory.costtype = case
when ( select maxvars.varvalue from maxvars where maxvars.varname = 'COSTFROMASSET' and maxvars.siteid = inventory.siteid ) = '1'
and ( select item.rotating from item where item.itemnum = inventory.itemnum and item.itemsetid = inventory.itemsetid ) = 1
then ( select value from synonymdomain where synonymdomain.domainid = 'COSTTYPE' and synonymdomain.maxvalue = 'ASSET' and synonymdomain.defaults = 1 )
when ( select maxvars.varvalue from maxvars where maxvars.varname = 'DEFISSUECOST' and maxvars.siteid = inventory.siteid ) = 'AVGCOST'
then ( select value from synonymdomain where synonymdomain.domainid = 'COSTTYPE' and synonymdomain.maxvalue = 'AVERAGE' and synonymdomain.defaults = 1 )
when ( select maxvars.varvalue from maxvars where maxvars.varname = 'DEFISSUECOST' and maxvars.siteid = inventory.siteid ) = 'STDCOST'
then ( select value from synonymdomain where synonymdomain.domainid = 'COSTTYPE' and synonymdomain.maxvalue = 'STANDARD' and synonymdomain.defaults = 1 )
else ( select maxvars.varvalue from maxvars where maxvars.varname = 'DEFISSUECOST' and maxvars.siteid = inventory.siteid ) end

If the Maximo database was originally built using MAXDEMO data, rows can exist in the Inventory table that do not have a valid SiteID. As UpdateDB populates new column Inventory.CostType, the invalid SiteID values prevent the script from determining values to populate CostType for these old MAXDEMO records.

Upgrade 7.1 to 7.5.

Diagnosing the problem

If this query returns any values, then your database contains Inventory records with invalid SiteIDs:

Select siteid From inventory Where siteid Not In (Select siteid From maxvars Where varname In
('COSTFROMASSET', 'DEFISSUECOST') ) ;

Resolving the problem

Since these Inventory records are old MAXDEMO data, they serve no purpose and should be removed from your database. Replace XX in the following statement with any invalid SiteID values returned from the query above:

Delete From inventory Where siteid='XX'

Restore your database to pre-upgrade 7.1, remove the bad rows from the Inventory table, and run UpdateDB over again.

Using the middleware installation program to install DB2 9.7 on a Red Hat v6 system results in an error related to missing prerequisites

Problem(Abstract)

Using the middleware installation program to install DB2 9.7 on a Red Hat v6 system results in the following error:

CTGIN9080E: libaio.so.1, libstdc++.so.5 and libstdc++.so.6 packages are
required for DB2.

This error can occur even if the prerequisite checking tool was used to verify prerequisites on the system.

Resolving the problem

The problem is solved by installing libstdc++-4.4.4-13.el6.i686.rpm

which installs /usr/lib/libstdc++.so.6 and /usr/lib/libstdc++.so.6.0.13.

Error CTGIN9053E reported when using the middleware installation program

Problem(Abstract)

When using the middleware installation program, an error similar to the following is displayed:

CTGIN9053E: The partition /data has 100618240 bytes free space, but the
deployment plan requires 1073741824 bytes free space on that partition.
Increase available space in /data.

In this scenario, the middleware installation program was launched from the /data directory, but was not selected as the destination directory for the installation.

Resolving the problem

This error occurs when the middleware installation program is started from a directory that does not include the free space required to install the middleware selected. This error will be reported even if you select a different file system to install the middleware into that does have sufficient space.

The solution to this error is to start the middleware installation program from the same partition as the default home location for users. For example, /home.