Saturday 18 June 2016

Differentiating ReportedBy and AffectedBy when using Classifications in SR

Question

I change the ReportedBy user in the Service Request but I'm not getting an updated list of classifications based on my new User. I can see the classifications that belonged to the original user. Why?

Cause

I'm creating an SR and I select ReportedBy User1, the list of classifications is populated but once I change that user to User2, the classifications aren't being updated based on the updated ReportedBy user.

Answer

The classification is filtered according to the Customer field. When you
add the User1 as Affected By, User1 is also added into Affected Person
that adds the Customer (customer) on the customer field. The customer field
is linked with Affected By person and not Reported By.
So when you change Reported By to User2, the Affected Person and
Customer fields are not changed. That is why an updated list in classifications is not being
displayed when you change the Reported By.


The customer comes from the Affected By, not the Reported By.

1. Go to SR app.
2. New SR
3. Entered Sinclair in Reported By. Sinclair also appeared in the
Affected By and Gillette appeared in the Customer field
4. Tabbed to the Affected By and replaced Sinclair by Reid. Received a
warning message about changing Customer value. I clicked on Accept My
Value.
5. Reid displayed in the Affected By field, and the Customer was
changed from Gillette to DCH.

Setting Site on SRs created from chats

Question

How do I change the default site that gets applied to a Service Request created from a chat so that it matches the SITE of the person who reports it?

Answer

1) Create a crossover domain with the following settings:

Name: SR_SITE
Object: PERSON
Validation Where clause: personid=:reportedby
Source field: LOCATIONSITE
Destination field: SITEID

2) Associate the created domain to the SR.REPORTEDBY attribute with Database Configuration

3) In the Attributes tab, select the REPORTEDBY attribute and click on the Edit Lookup Map button that is beside the trash button

4) Create a lookup map with the following settings:

Target Attribute: SITEID
Source Object: Person
Source Key: Locationsite
Sequence: 1
Allow Null: checked

With that setting the livechat will be creating SRs, where the SITEID will be the same of the REPORTEDBY Site id.

Note that it is required that the Person record, in the Peoples applications have the Person's Site set.

Relating incident records to global issue not working



Problem(Abstract)

From an Incident select "Show Similiar Tickets' from action menu, check the relate incident records , click the 'relate records to global issue' , receive 'bmxaa4187e relationship called does not exist for the TICKET business object'

Cause

System does not allow you to relate incidents to global incidents.

Resolving the problem

Add the following relationship to the INCIDENT object.
Field Value
Relationship GLOBALINCIDENT
Where Clause ticketid=:globalticketid and class='INCIDENT'
Child Object INCIDENT
Remarks Relationship to the global incident for this
incident

Advance Search and Save Query buttons

Technote (troubleshooting)


Problem(Abstract)

The Advanced Search and Save Query buttons aren't showing up in View Service Requests application.

Symptom

These buttons are missing from the application.

Diagnosing the problem

Go to Self Service -> Service Requests -> View Service Requests. The bottom table is View Service Requests. The table looks like this:

Resolving the problem

Go to System Configuration -> Platform Configuration -> System Properties.
Search for mxe.webclient.searchMenubar.
Set the Global Value to = 1.
Save.
Click the checkmark next to property name and hit Live Refresh

Now if you go back to View Service Requests this is how it looks:

Service bulletin warning dialog in incidents and service requests

This document applies only to the following language version(s):

English

Question

How to enable or disable the service bulletin warning dialog in incidents and service requests application

Answer

Procedure:
1. Open the System Properties application (Go To > System Configuration > Platform Configuration > System Properties).
2. Click Filter.
3. In the Property Name field, type the first few letters of the property that you want to modify, and press Enter.
This is the property Name:
pmcom.ticket.enable.serviceBulletinWarningDialog

4 Open the property, and in the Global Value field, enter 1 to enable the dialog or 0 to disable it.
5 Click save 
6 Check the box beside the name of the property that you have modified, and click live refresh  to refresh the system properties to include your modification.

Adding button to row of buttons on top of app

Question

How to add a button to the top of the app?
 For example, how to add the "Take Ownership" button to the top of the Service Request (SR) app?

Answer

To add the Take Ownership button to the toolbar of the SR app, follow these steps.
Note that step #8 is not necessary for the Take Ownership button but may be necessary for other actions that do not appear in the left pane.

1) Go to -> System Configuration -> Platform Configuration -> System Properties

2) In Global Properties - filter by mxe.webclient.showOnToolbar

3) In Global Value - Add OWNERSHIP. OWNERSHIP is the action for "Take Ownership". Use the action for the button you wish to add.
For example, the value will be something like this:

INSERT,SAVE,CLEAR,PREVIOUS,NEXT,NAVHISTORY

Instead change it to this:

INSERT,SAVE,CLEAR,PREVIOUS,NEXT,NAVHISTORY,OWNERSHIP

That is, add OWNERSHIP. Where you add it does not make a difference in how it is displayed, so just add it to the end.

4) Save

5) Check the mxe.webclient.showOnToolbar and click on Live Refresh

6) Click OK

7) Go to -> Service Desk -> Service Request

8) The icon should appear in the toolbar. If it does not, then go to App Designer and select "Add Modify Toolbar Menu".
Add a new row with these values:

Element Type: OPTION
Key Value: OWNERSHIP
Position: (give it a number to determine where it shows relative to the over button's values)
Subposition: 0
Image: nav_icon_takeOwnership.gif
Visible: mark the checkbox
Access Key: CTRL+ALT+T
Tabs: All

Now #8 should already be set up for you. There should already be an
OWNERSHIP value but I am putting it here so you know all the steps
involved in making this button appear. Remove either the property or
the row, and the button will disappear.

How to add Service Request Attributes in a Communication Template

Question

How do I access Service Request attributes within a communication template?

Answer

You can get the attributes by using a relationship to the object. For instance, if the Communication is created in the Incident application, you can use relationship ACTIVITY to get the attributes of any of the
activities of the Incident. If the Communication is generated from the Activity object, use relationship ORIGTICKET.

If the relationship returns more than 1 record, treat it as an array. For instance, if the Incident has 3 Activities, the :ACTIVITY relationship can return 3 objects. Use brackets to refer to them.

For example, :ACTIVITY[2].CINUM gets the CINUM of the 3rd Activity of the Incident. 

Removing Remote Diagnostics from the context menu

Question

How to remove Remote Diagnostics menu option from ticket apps? We have a tool already for this, and do not want our users to see the Remote Diagnostic option.

Answer

Go into Application Designer and export the MENUS system xml. Save a back up copy of it. Then modify it. Search for the word "remote". You will find 4 lines. These are various menus used off the Asset or CI attributes to launch the Remote Diagnostics. Delete these four lines and import the xml back in.

Thursday 9 June 2016

How to Delete Websphere Application Server Profile ?

First list all profiles on a server:
List the profile using one of these commands

  • Windows: was_install_dir\bin\manageprofiles.bat –listProfiles
  • UNIX/Linux: was_install_dir/bin/manageprofiles.sh –listProfiles

Remove a WebSphere Application Server profile:
Delete the profile using one of these commands:

  • On Windows: was_install_dir\bin\manageprofiles.bat –delete –profileName profile
  • On UNIX/Linux: was_install_dir/bin/manageprofiles.sh –delete –profileName profile

Ensure that references to the deleted profile are removed from the profile registry by running the following command:

  • On Windows: was_install_dir\bin\manageprofiles.bat –validateAndUpdateRegistry
  • On UNIX/Linux: was_install_dir/bin/manageprofiles.sh –validateAndUpdateRegistry

Delete the profile directory tree (if it was not deleted by the previous action).
Delete the profile Directory using one of these commands:

  • On Windows: was_install_dir\profiles\rmdir /s profileDirectory
  • On UNIX/Linux: was_install_dir\profiles\rm -R profileDirectory

Maximo Integration Framework (MIF). Which Components to Use?

How do I determine which integration components to use for my integration scenario?
This is a common question for those who are not familiar with the I-F.  Reasons for choosing the use of certain I-F components is often decided based on one or more of the following:
  1. The integration capabilities of the application being integrated to Maximo
  2. The integration skills of the developers who will implement the integration
  3. The need to have the integration processing occur in a synchronous or asynchronous manner
  4. What level of error management is required and what level is supported by the external application
  5. Do integration messages need to process based on events (ie. approval of a Work Order)
  6. Does the integration need to operate in a batch or real-time (near) mode.
  7. Is the I-F being used to support implementation data loading
  8. Will the integration be deployed using a common ESB layer within your enterprise
The above list is not intended to be all-inclusive, but it should give you an idea of the types of things to consider when planning integration with Maximo.  Keep in mind, large integration deployments could involve many systems and require different integration components to be used for different external applications.
To help answer the stated question above, you need to start by having a general understanding of the capabilities offered by I-F. 
The I-F is a framework that supports the sending and receiving of XML messages for querying and updating of the data in the Maximo Business Objects (MBOs).  Although the framework is based on data messages in an XML format, there is support for other data formats such as .CSV, Database tables and JSON.
Beyond the format of the data, there is support for sending/receiving data in an asynchronous manner by placing integration messages into JMS queues. This allows the sender (either Maximo or the external application) of the message to drop the message to the queue and not wait until the message is processed by the receiving application.  There is also support for synchronous process where one system may query the other system for data and take the response of that request for use in its application processing.
The I-F provides support for a number of common integration protocols that a customer may choose to integrate with.  Some of the most common include HTTP Post of XML, SOAP-based web services, JMS queue to queue, Files (XML or .CSV) and interface tables (DB).  The choice of which integration protocol is often made based on the capabilities of the external application (ie. external app only supports SOAP messages) or the capabilities of those who will implement the integration (ie developers are strong with PL/SQL and DB access, not familiar with XML).
In addition to the above, other features of the I-F include:
  • Support for customizations using processing rules, java classes or XSL
  • Event based processing where an event in Maximo will trigger the sending of an integration message to an external application
  • Error Management application that allows for an administrator to view messages in error, provide corrections to messages and initiate the reprocessing of messages
  • Support for RESTful interactions where external application can retrieve/update Maximo data as REST resources
  • Enabling OSLC interactions where resource links can be saved in Maximo and used to view external resource data using the delegated UI of an OSLC Provider application.
Now that we have discussed the general capabilities of the I-F, let's look at the individual components that provide this functionality.
There are 3 main layers of the I-F.  The most important is the Object Structure layer.  This layer defines the content (Maximo objects and attributes) of the message (XML schema). A number of object structures are provided 'out of box' with the products and there is also an object structure application where new/custom object structures can be created by customers/implementers. Below depicts the MXPO object structure content that supports the creation and updating of a Purchase Order in Maximo. 
The object structure identifies the objects (PO, POLINE, POCOST and POTERM) and its attributes that make up the message content (schema).  Object structures can be defined for any objects that are registered in the Maximo Data Dictionary (DD), including custom objects. Channels and Services include a reference to an object structure that identifies the content of the message within the channel or service.  An object structure can also used for integrating data stand-alone.
The Channel/Service layer is used to process an outbound (Channel) and inbound (Service) message. This layer is primarily used to implement filtering and perform data mapping or business rules that are specific to the integration processing.  Like object structures, there are a number of channels and services provided 'out of box' and there are applications provided to create new/update existing channels and services.  The last layer supports the sending and receiving of the messages.  The End Point definition defines the protocol to be used when sending a message out of Maximo.  The external system represents the application being integrated with and identifies the end point and all the channels and services being used with that external application.  Depending upon your integration scenario you may need to use/configure all 3 layers or just the object structure layer.
When evaluating I-F components for your integration scenario, it is common to consider outbound integration separate from inbound. Outbound integration is when Maximo is the sender of the message to the external application.  Inbound integration is when Maximo is the receiver of the message from the external application.
Outbound Integration Scenario
To support outbound integration scenarios, the I-F provides 2 Channel components, Publish and Invocation.  The Publish Channel is the more commonly used channel and it provides the means to send an outbound message based on an event in asynchronous model.  The Invocation Channel, supports a synchronous message processing where the response of the request from the external application may be used to update a Maximo object.

The Publish Channel can be initiated from an event (on left in image above), such as an update of an asset, or by an admin user performing a Data Export on the Channel.  The XML message is created by the object structure tied to the channel and then the message processes through the channel layers before dropping to the outbound JMS queue.  In the case of an event based message, the Maximo user's transaction (the user updating an asset record) will be committed after confirmation that the message was saved to the JMS queue.  The Processing layers in the channel are where the implementers could choose to use the processing rules, Java code and/or XSL to modify the message, perform business rules or transaction filtering. Processing of messages out of the queue is done (by default) by the JMS CRON task. Messages retrieved from the queue are processed in a strict FIFO (First In-First Out) order and messages are delivered to the external application as defined by the configured End Point in the External System application.
The Invocation channel can be initiated from an action class (class provided with product).  The XML message is created by the object structure tied to the channel and the message processes through the channel layers before invoking the End Point configured on the channel (there is no external system configuration for an invocation channel).  The Processing layers in the channel are where the implementers could choose to use java and/or XSL to modify the message, perform business rules or transaction filtering. Since the processing is synchronous, the response of the invoked service is returned to the channel and the implementer can provide code to have the data mapped to a Maximo object structure for updating or could display the data from the response in the Maximo UI if desired.
The most common points (not all) to consider when deciding on which channel to use is:
  • If you need event-based message processing:    Publish Channel
  • if you need an asynchronous processing model: Publish Channel
  • if you need a synchronous processing model:     Invocation Channel

Inbound Integration Scenario
To support inbound integration scenarios the I-F provides 3 Service components, Object Structure, Enterprise and Standard.  The Object Structure and  Enterprise Service provide support CRUD (create, replace, update, delete) operations on the MBOs that are defined in the object structure. Standard services are more fine-grained service for specific actions of a MBO such as change status or move asset.  Choosing between the use of an object structure service versus an enterprise is dependent upon the integration scenario and integration capabilities of the application calling the service.  The table below summarizes the capabilities of each service:
FeatureObject Structure ServiceEnterprise ServiceEnterprise Service
ProcessingSynchronousSynchronousAsynchronous
Options to invokeEJB, Web Service, HTTP Post,File (XML or .csv),REST, OSLCEJB, Web Service, HTTP PostEJB, Web Service, HTTP Post, JMS, File (XML or .csv), DB Tables
CustomizationnoneYesYes
XML formatRequires Maximo XMLMaximo or external XMLMaximo or external XML
ConfigurationLess: requires object structure configurationmore: requires object structure, enterprise service & external system configurationmore: requires object structure, enterprise service & external system configuration
So from the table above there are some very clear choices in certain cases.  If you want to leverage interface tables then your only option is to use enterprise services in an asynchronous model.  If you are integrating using REST or OSLC then your only option is to use object structure services. If you need to leverage customization points during the processing of an inbound message then you need to use an enterprise service (using a sync or async model). If you want your external system to call a web service synchronously and that system will provide Maximo XML, you can use either service type.  However, you may choose to use the object structure service simply because it requires less configuration in Maximo.


The object structure service allows synchronous calls to query and/or update Maximo data.  When calling, data must be a in Maximo XML format and there are no customization layers to manipulate the message.  Object structures are also use for Application-based importing where the data can be in either an XML (Maximo XML) or .CSV format.  This loading process is intended to be for relatively small amounts of data (not for loading 1000's of records).  See this link for more information application importing.


The Enterprise Service offers the most capabilities for inbound processing.  It support many protocols, offers synchronous and asynchronous processing models and provide implementers multiple choices for customization.  Probably the most common use of enterprise services is using either XML over HTTP or as a Web Service (SOAP).  In addition, the use of file loading (either .CSV or XML) and integration through interface tables is heavily used as well.  In terms of which protocol to use, this is often based on the external systems capability.  If your external application can only invoke a SOAP web service then the enterprise service needs to be deployed as a web service. 
In terms of whether to use JMS (aync) or not, may depend on whether your external application requires an immediate confirmation that the record in Maximo was created/updated successfully.  One key factor here is that if you choose to not use JMS (sync processing), then the external application owns the responsibility of managing errors that may be returned to it from Maximo and it also must manage the errors and subsequent re-processing of the message to Maximo as needed.  When posting a message to the Maximo inbound queue (async processing), the external application only gets confirmation that the message made it successfully to the queue.  Any problems in processing the message from the queue into Maximo would be managed in Maximo by an administrator using the integration Message Reprocessing application where integration messages that hit errors can be viewed and managed.
The Standard Service is a fine-grained service for operations such as Change Status or Asset Move.  These services require method annotations to be done in Application services.  At this time there is a small number of services available and the use of these services is relatively small when compare to object structure or enterprise services.  Standard Services can be identified using the Web Service Library application.  In some cases, such as Change Status, the same functionality is available through the object structure.

Batch file for starting Maximo services

sc start "IBMHTTPServerV8.5"
timeout 5

sc start "IBMWAS85Service - ctgCellManager01"
timeout 5

sc start "IBMWAS85Service - ctgNode01"
pause

Adding Hover Dialogs to additional fields in Maximo 7.6

Question

How can I add Hover Dialogs to additional fields in Maximo 7.6?

Answer

Hover Dialogs are a new feature in Maximo 7.6 that display additional information
related to a field when you hover your mouse over the field. For example in the image
below, if you hover over the Reported By field in Work Order Tracking, it will display
additional details on the value in the field. The hover option is only available if there is
an existing value in the field.



These hover dialogs are set up by default on a number of fields in various applications
and based on the following attributes:
- Asset
- Item
- Person
- Work Order

In order to add an additional hover dialog go to System Configuration / Platform Configuration / Application Designer and pull up the application your field is in (in this example that is the
Supervisor field in the Labor application). Next right click on the field, select "Properties", and then click on the Advanced tab. Add PERSON_RECORDHOVER in the Hover Window ID textbox to
add more person details and then save your changes.



Now when you Go To the Labor application and if your Supervisor field has a value in it, then
hovering over the field will show additional details about the supervisor.



Please note that the hover dialogue only works when there is a field validation class, or a table domain connected to the attribute. If you add hover functionality to an attribute which doesn't have a field validation class, such as the ASSET.CHANGEBY, or SR.ENTEREDBY, then the hover dialog will display but it is blank, it does not show any data.

IBM Readme for IBM Maximo Asset Management 7.6.1.3 Fix Pack

  Fix Readme Abstract This fix pack updates IBM® Maximo® Asset Management version 7.6.1, 7.6.1.1, and 7.6.1.2 Content IBM Maximo Asset Manag...