Wednesday, October 31, 2012

Using Job Plans and Preventive Maintenance in Maximo 7.5

Job 02
Using Job Plans and Preventive Maintenance in Maximo 7.5 guide will introduce you on creating job plans and preventive maintenance records for periodic maintenance and inspections to be performed on an asset. This guide will also discuss on how to associate Job Plans to Preventive Maintenance. This enables users to automatically generate work orders for the maintenance of all assets and locations in a scheduled time.

Maximo Job Plans will help end users to create an organized approach for future work activities. These serve as templates for future work activities that are done regularly or repetitively.
Job Plans when created have an initial status of DRAFT. This status needs to be changed to ACTIVE status before it can be used on a Work Order or associated with Preventive Maintenance Record. A job plan record may be used countless times by inputting the Job Plan number in the Job Plan field of Work Order Tracking, or by associating it with a Preventive Maintenance record. The Preventive Maintenance record will be used to generate periodic Work Orders. Using Job Plan records will help users save time, since users don’t need to manually enter the operating steps, planned labor, and material resources each time a PM work order was generated.
Job 03
Job Plan Screen:
Job 1
Job 1-2
1.Sign in to Maximo
Job 2
2.Go to > Planning> Job Plans to open the Job Plan application.
Job 3
3.Click the New Job Plan button.
Job 4
4.Enter a value for the Job Plan record number and all other required fields. Required fields contains asterisk (*) before the field label.
Job 5
5.Save the record by clicking the Job 6 icon on the toolbar.
Job 7

Primary Job Plan Fields
Job Plan
This is the unique identifier for Job Plan to easily identify the record.
Description
Provides a short description for a Job Plan. A long description field beside this field that can be used when a record needs a longer and more specific instruction details.
Organization/Site:
If these fields are left blank, this means that the Job Plan can be used to all Organizations or Sites. Use these fields to limit the Job Plan record to a specific Organization or Site.
Status
Newly created Job Plans begin with a status of DRAFT. Job Plan records which have DRAFT status cannot be associated with any records. Job Plans should be changed to ACTIVE status before you associate it with Work Orders or PM records. Another status which will block the functionality within other application is INACTIVE status.
Template Type
This field allows users to create a division for Job Plan types. Types include Activity, Maintenance, and Process.
WO Priority
Priority of Work Orders to be generated.
Supervisor
This will indicate the Supervisor which will take the responsibility of the generated Work Order.
Duration
Duration of time to complete the task.
Lead
Defines the Lead person who will be copied to the work order created with this job plan
Work Group
Designated Person Group for the Work Order.
Owner/Owner Group
The person or person group who will be responsible for the created Work Order.
Interruptible
Identifies if the task must be completed in a single setting, or it can be started and stopped.

Job 8
1.Click the New Row button in the Job Plan Tasks section.
Job 9
2.Enter a number in Task ID field, or accept the default number.
Job 10
3.Optional: Enter a description of task in the Description Field.
Job 11
4.Enter a sequence number and estimated time for completion, if needed.
Job 12
5.Repeat steps 1-4 until all tasks have been added to the Job Plan record.
6.Save the record.
Job Task Fields:

Task ID:
This is the unique identifier of tasks under a Job Plan record. A required field which is non-editable when the record is saved.
Description
Describes the Task to be completed for the Job Plan. Long description can also be included using the long description button beside the field if the task needs a more detailed description.
Duration
Time needed to complete the Task.

Job 13
Job plan estimates can be added to record all planned Labor, Materials, Services, and To
1.Click the New Row button on the sub-page tab where you want to create an estimate.
Job 14
2.If the selected labor needs to perform a specific task on the job plan. Leave it blank if not needed. The image below indicates that the labor Mike Wilson will perform the Task 10 of the job plan record.
Job 15
3.Another option is that you can modify the set estimated hours for Labor or uantity for Materials, Services and Tools.
4.Repeat steps 1-3 until all estimates have been added to the Job Plan.
5.Click Save button to complete.
Job 16
You can register Locations and Assets on a Job Plan using the work Assets tab.
1.Click the New Row button under Work Assets tab.
Job 17
2.Select Location or Asset using the lookups.
Job 18
Job 19
3.Click Save when done.
Job 20
Instead of listing individual task in a job plan, you can use the nested job plans option which will enable you to add a job plan record that contains tasks needed for the associated job plan. This is a useful feature in a job plan as it will save time for the users to load Job Plans for assets with different build types. For example, your Organization has a default sets for cleaning air conditioners. However, cleaning of other brands may require additional unique steps to properly check the unit.
In the example below, Task 30 is to check Freon level. A job plan for HVAC System Inspection is nested into Task 30.
Job 21
When the created job plan that contains nested job plan record is included to a Work Order, the main tasks will be included on the primary Work Order. A Child Work Order record will be created which contains the steps for HVAC System Inspection.
Job 22
Preventive Maintenance (PM) records are used to generate preventive maintenance work orders. Job plans can be incorporated in a preventive maintenance record. This is commonly used on assets and locations that require periodic maintenance to maximize the performance and avoid untimely failures. This is necessary for Organization to extend useful life of their assets and locations.
Job 23

Preventive Maintenance Fields:

PM Number
This is the unique identifier of a Preventive Maintenance record. Every PM record is specific only to one Asset or Location record.
Description
Describes the Preventive Maintenance record
Location/Asset
Asset or Location where the preventive maintenance will be done.
Route
A route is a list of stops that represent asset or work locations. If a work order is generated from a PM that has associated route, a parent work order will be created for the associated asset or location and a child work order for each asset in the route list.
Lead Time (Days)
This indicates the number of days to be considered before the actual work can be started. For example, it will take 2 days to deliver the spare parts needed. You just need to input the number of days in this field and this will be added to the number of days entered in the Generate Work Order dialog box. When using Lead Time option, ensure that the Lead Time Active check box is checked.
Counter
This indicates the number of generated work orders from the PM since the first generation of the record. This resets when a new PM record is inserted.


Welcome to the final part of series about Using Job Plans and Preventive Maintenance in Maximo 7.5

Use Job Plan Sequences
When checked, this indicates that the PM uses job plan sequences which will generate different work orders each time based on a job plan sequence. If it is left unchecked, PM will generate the same work orders every time.
Work Order Status
Indicates the status of the PM. Newly created PM records will have a DRAFT status and Active status for active PM’s and INACTIVE for non active PM’s.
Supervisor
Contains the supervisor name that will be responsible for assigning resources such as Labor to Work Orders generated from the PM.
Storeroom
If a Job Plan has estimated materials, Maximo needs to know the Storeroom to create the item reserved.
Lead/Work Group/ Owner/Owner Group
This will contain on which person or group is responsible for the work activities of generated Work Orders.
WO Priority
Priority to be set for the work order to be generated.
Interruptible
If checked, the work order is allowed to be stopped and restarted. If unchecked, the work order should not be interrupted.
Job 24
Scheduling of PM Work on most assets can be done on a date driven basis, daily, weekly, monthly, quarterly or annually. For other assets, usage function can be used to schedule a preventive maintenance work. Maximo 7 also supports dual triggers. For example, a car requires an oil change every 3 months or 5000 kilometers, whichever comes first. Maximo will generate a work order record for a preventive maintenance work once the car reached the 5000 kilometers or 3 months whichever comes first.
Job 25
This controls the timing of Work Order generation under the selected PM record. There are 2 types of frequency that can be used:
Job 26
1.Time Based Frequency – This can be used when you need to schedule the generation of Work Order generation by calendar unit. Choices include days, months, weeks, years.
2.Meter Based Frequency – Generation of Work Order will be based on meter readings.
Job 27
PM Work Orders can be generated automatically or manually. In able to generate it automatically, there is a Cron Task available which is called PMWoGenCronTask. Maximo user with administrative privilege can schedule the generation of PM Work Order using the Cron Task Setup. Once the Cron Task is activated, Maximo will begin to execute the process depending on the schedule setup.
Manual PM Work Order generation lets the assigned person to generate their own PM Work Orders on the time they want. Always consider that only active PM can generate work orders.
1.Go to PM Application
2.Select the PM you want to generate a PM Work Order
3.Go to Select Action Menu.
4.Fill in the necessary details.
Generate WOs Due Today Plus This Number of Days
Gives additional days before the PM Work Order should be generated.
User Frequency Criteria
This field is checked by default. This will look at the next due date of the PM record to determine if it needs to generate a Work Order. If this field is left unchecked, this will disregard the frequency settings and will generate a Work Order whether the due date has been reached or not.
Run Work Order Generation in Background
If this field is checked, users can continue working on their Maximo screen without interrupting the generation of work orders. If left unchecked, the generation activity window will be shown.
Notification E-mail
The e-mail address listed in this field will receive a copy of the PM log file when the PM Work Order generation has completed. This includes the PM and Work Order numbers generated.5.System message will be displayed containing the details for the generated PM Work Order.

Job 29
5.System message will be displayed containing the details for the generated PM Work Order.

Tuesday, October 30, 2012

Migration Manager

Migration Manager Overview
Migration Manager Application
The Migration Manager application is used to migrate configuration content from one product environment to another.
You manage the configuration content that you want to migrate in the form of package definitions and packages. As part of your implementation of a migration process, you use the Migration Manager application to define and create the package definitions, and then distribute and deploy the packages.

For example, you can migrate configuration from a development environment to a test environment. After testing, you can migrate the configuration to a production environment. The development environment is the source and the test and production environments are targets. You can use this approach during the initial configuration of the product or at any time when you want to change your configuration of the product.


The Migration Manager application has the following tabs:
  • The Migration Manager application has the following tabs:
  • List: To search the Migration Manager application for package definitions.
  • Package Definition: To define, save, approve, and activate package definitions.
  • Package Definition Structure: To view the hierarchical structure of a package definition.
  • Distribution: To distribute a package from a source to a target environment.
  • Package: To create, distribute, and deploy physical packages.
  • Messages: To view detailed messages about the creation or deployment of physical packages.
List Tab
You use the List tab to search the database for a specific record or group of records that meet your criteria. You use the filter fields located above the List table window to enter basic search criteria.
The List tab has an Search Toolbar with the following links:
Advanced Search: Select from a list of the following options:
More Search Fields
Enter Where Clause
View Search Tips
Save Query: Select from a list of the following options:
Save Current Query
View/Manage Queries
Package Definition Tab
You use the Package Definition tab in the Migration Manager to create package definitions, which are templates for individual packages. A package definition organizes the content to be migrated, and must be created before other migration activities occur.
Header
The header area identifies the package definition and provides status information.
Migration Groups section
Each row in the Migration Groups section contains the following attributes:
Migration Group - Name of the migration group.
Description - Description of the migration group
In this section, you can add migration groups to or delete migration groups from a package definition.
You can also set conditions for migration objects within a migration group in a snapshot package definition by clicking Set Where Clause .
To view dependent migration groups, click View Details to the left of the Migration Group row.
Dependencies section
The Dependencies section lists the groups that the current migration group is dependent on. The dependencies are the relationships between the underlying migration objects in the database. In this section, you can see whether a set of configuration data in a migration group depends on another set of configuration data in a different migration group.
Compiled Sources section
In the Compiled Sources section, you can add or delete information about compiled sources to or from a package definition.
Each row in this section contains the following attributes:
File Name - Name of the compiled source file.
Description - Description of the compiled source.
Package Definition
Migration Groups and Compiled Sources
Package definitions can contain migration groups and compiled sources.
Migration groups
A migration group is a collection of related migration objects. A migration object is a group of related business objects (database tables).
You use the Migration Groups application to define and aggregate configuration objects, which simplifies the creation of package definitions.
Compiled sources
You can include references to compiled sources in a package definition. A compiled source is any file that is outside the product database, but is part of the Enterprise Archive (EAR) file. Compiled sources can include many types of files, such as class files, archive files, image files, and properties files. Compiled sources are typically in folders of the product installation, but can also be on the local client computer or on a mapped network drive
If you need to migrate multiple compiled source files, combine them into a single EAR file to simplify the migration process.
Header Area of the Migration Manager Tabs

The Package Definition, Package Definition Structure, Distribution, Package, and Message tabs all have a header area to identify the package definition and provide status information.
The header area has the following fields:
Package Definition Name - The name of the package definition.
Source - The name of the product source environment where you defined the package. This name is a combination of the database host name, the database identifier, and the database schema name. The source name helps you to identify where the data comes from. The source name is also used in the name of a package to ensure that every package name is unique.
Type - The type of package definition. A package definition can be a snapshot or a change. You specify the type when you create a package definition.
Batch Size - Specifies the number of records to be retrieved at a time when a package is created. The default value is 100.
Change Role - Specifies a designated role. Only changes made by users in this role are captured by the Migration Manager application when a change package is created.
Status - An indicator of the migration activities that can be performed on the package definition. The status can be WAPPR (waiting for approval), APPR (approved), or LOCKED.
Active - If selected, indicates that you can create a package from the package definition. For a change package definition, this check box indicates that the event listeners are registered and that the Migration Manager application is capturing change information. An active package definition cannot be modified. A package definition must be active before it can be used to migrate data.
Change By - The user who last changed the package definition.
Change Date - The date that the package definition was last changed.
Package Definition Structure

Package Definition Structure Tab

You use the Package Definition Structure tab to view a hierarchical representation of the content that can be in the selected package definition. The hierarchy shows the following information:
The migration groups in the package definition
The migration objects and objects structures in each migration group
The business objects within each object structure
Any compiled sources in the package definition
Hierarchy section
The hierarchy section shows the information about the package definition in nested levels. The root entry of the hierarchy is the name of the current package definition.
The root entry can have the following entries:
Migration Groups - The migration groups in the package definition and the migration objects in those groups. This level can also have a Dependencies entry, which shows the migration groups that a particular migration group depends on.
Package Metadata - The metadata that describes the package definition.
Compiled Sources - The compiled source files that are included in the package definition. Each entry shows the absolute path and file name.
Distribution Tab

You use the Distribution tab to associate targets with a package definition and to change or delete these associations.
 
Distributions section
Each row in the Distributions section has the following attributes:
Target Name - Name of the environment to which the package based on the package definition can be distributed.
Description - Description of the target environment.
Type - The type of target, either DATABASE or FILE, depending on whether the target is a remote database or a file on a file system.
Database URL or File Path - The database URL or absolute path on a file system that is accessible to the application server.
To view details of a distribution, click View Details to the left of the distribution row. To delete a distribution, click Mark Row for Delete to the right of the distribution row.
Target Details section
The Target Details section includes the following fields:
User Name - User name for the target database.
Schema Name - Name of the database schema.
Change By - The ID of the user that last modified the distribution definition.
Change Date - The date and time of the last changes to the distribution definition.
Package Tab
You use the Package tab to perform the following tasks for a package definition:
Create or delete a package
Distribute or redistribute a package
Download compiled sources in a package
Download a package
Deploy a package
Close a package
Packages section
Each row in the Packages section includes the following attributes:
Package - Name of the package, which is a combination of the package definition name and the source information.
File Name - The name of the package with the archive file extension. For a package with a database as its target, this field is empty.
Status - Status of the package.
Status Date - The date when the status was applied to the package.
To view detailed information about a particular package, click View Details
Package Details section

The Package Details section shows the following fields for the selected package:
Package - The name of the package. The name is a concatenation of the package definition name, source, and date and time of creation, separated by underscores. For example, if the package definition is MyTest, the source is ServerA and the date and time is 10 July 2008, 16:00:00, the package name is MyTest_ServerA_20080430160000.
Status - Status of the package.
Progress Status - Indicates the progress of the package processing in the source or target environment.
File Name - The file name that corresponds to this package if a package file is generated
Direction - Specifies whether the package is outbound (from the source environment) or inbound (to the target environment).
Redistribution Source - The source information from where the package is being redistributed. This value is the combination of database identifier, database schema, and database host name. These values are retrieved from the database server in the environment from where the package is to be redistributed. The redistribution source is not the original source of the package.
Change By - The user who last changed the package.
Status Date - The date and time when the package was last changed.
Readme Information - The information that was entered when the package was created.

SubTabs
The Package tab has tabs that show more information about the selected package.
Manifest tab
XML-formatted information that represents the content of the package and the version information. This information is used in the target environment to deploy the package.
Status History tab
The status and progress status of the creation and deployment of the package. This tab has the following fields:
Status - The status of the package.
Progress Status - The progress status of the package.
Memo - Information about the change of status.
Status Date - Date and time when the user changed the status.
The Details section shows the following additional fields:
Redistribution Source - Indicates whether the status change was caused by a redistribution of the package. The value shows the environment from where the redistribution was initiated. If the package is not a redistributed package, this field is empty.
Change By - The user who changed the status.
Change By - The user who last changed the package.
Status Date - The date and time when the package was last changed.
Readme Information - The information that was entered when the package was created.
SubTabs
The Package tab has tabs that show more information about the selected package.
Manifest tab
XML-formatted information that represents the content of the package and the version information. This information is used in the target environment to deploy the package.
Distribution Tracking tab
Information about the history of the distributions of the package to the target environment. Primarily indicates the success or failure of the distributions This tab has the following fields:
Target - The environment to which the package was distributed.
Status - The status of the distribution.
Status Message - A message about the distribution.
Distribution Date - The date the package was distributed.
The Details section has the following additional field:
Distributed By - The user who distributed the package.
 
Migration Groups Application

You use the Migration Groups application to organize and group configuration content that you want to migrate. After you set up the configuration content in migration groups, you can include these groups in package definitions in the Migration Manager application. Migration packages can be created from the package definitions and these packages can then be migrated to another system or environment.
You can work with migration groups that are included with the product (internal migration groups) or you can create your own (user-defined) migration groups.
The Migration Groups application has the following tabs:
List: To search for migration groups.
Migration Group: To create, view, modify, or delete migration groups.
Migration Group Structure: To view in a hierarchy the migration objects that are contained in a migration group.
Migration Groups Application List Tab

Migration Group Tab

You use the Migration Group tab in the Migration Groups application to define new migration groups and their dependencies. You can use these new migration groups in package definitions that you create in the Migration Manager application. The Migration Group tab has the following sections:
  • Header
  • Migration Objects
  • Dependency
Header section

The header section has the following fields:
Migration Group - The name of the migration group.
Migration Group Order - Assign the correct order to migration groups to ensure correct sequential processing of configuration data. If migration groups are not ordered correctly, the deployment of migration packages that contain these groups using the Migration Manager application might fail. For example, if records in migration group B are dependent on records in migration group A, specify the correct ordering to ensure that the Migration Manager application inserts or updates the records from migration group A into the target database before inserting or updating the records from migration group B.
Internal - If this check box is selected, the migration group is included with the product. The check box is read only. You cannot modify internal groups.

Migration Objects section

The Migration Objects section displays the migration objects in a migration group. You can view the migration objects or add objects to a migration group that you create. Each row in this section contains the following attributes:

Migration Object - The name of the migration object.

Description - The description of the migration object.

Migration Object Order - The order of the migration object within the migration group. Objects are processed in sequential order during the create and deploy tasks of the migration process. The value must be unique within the migration group.

As a default, the next sequential value is assigned.

When a package is created, the Migration Manager application checks the object order to determine the sequence in which the migration object are processed. When a package is deployed, the Migration Manager application first populates tables in the target database with parent records, and then populates related tables with the related child records.

Internal - If this check box is selected, the migration object is included with the product. You cannot modify internal objects.

To view detailed information about a particular migration object, click View Details to the left of the Migration Object row.
 
Example of migration object ordering
You can use the BPM (Business Process Management) migration group to move workflow processes. This migration group contains the following migration objects, which must be processed in the order shown:
DMACTION
DMROLE
DMCOMMTEMPLATE
DMESCALATION
DMWFPROCESS
The order must be followed because a workflow process might refer to one or more actions, roles, communication templates, or escalations. Similarly, an escalation might refer to one or more actions or communication templates, and a template might refer to a role.
If these objects are not processed in this order, the migration might fail, because the system might attempt to insert a record into a table before inserting a related and required record into a related table.
Dependency section
The Dependency section lists the groups upon which the migration group that is shown in the header section (the current migration group) is dependent. These dependencies indicate relationships between the underlying migration objects in the database.
To view detailed information about a dependency, click View Details to the left of the Dependent Migration Group column in the Dependency row.
Migration Group Structure Tab
Use the Migration Group Structure tab to view a hierarchical representation of the currently selected migration group, its migration objects, and the business objects of each migration object.
This tab also shows the dependent groups of the currently selected migration group, the migration objects, and the business objects of each migration object.
When you select this tab, the hierarchy is shown collapsed. Expand the hierarchy by clicking the plus symbols .
Object Structures Application
You use the Object Structure tab to identify the objects and data fields that comprise an object structure. You also use the Object Structure tab to define the following characteristics of the object structure:
Which system application consumes the object structure
Whether you can use the object structure to create, update, and delete object content or to restrict the object structure use to query and to publish object content
Whether you can use the object structure to represent a non-hierarchical structure (flat file data)
The objects you can include in the object structure and the relationships between the objects
The processing sequence for child objects that share the same parent object
Migration Of Configuration
Migration task flow
1 Define - The process of creating a package definition in your source environment. A package definition defines the boundaries of what product configuration content you want to include in packages based on the definition.

2 Create - Prepare a package instance containing the product configuration content based on the package definition.

3 Distribute - After you create a package, you distribute the package to one or more appropriate target environments. You must distribute a package to a target environment before you can deploy it to that environment. You can distribute to a database target or file target. Distributing to database is useful
when migrating data from development to test. Distributing to file is useful when distributing from test to production, where direct access to a production database might be strictly controlled.

4 Deploy - Directly apply the product configurations contained in a package into the target environment. Back up your target database before you deploy a package to that environment. To preserve the integrity of structural changes, you can only deploy one package at a time.
 

IBM Maximo 7.5 login screen changing

IBM Maximo 7.5 login screen changing

That was my first task assigned by our team lead and we have done lots after that :D.
To change the original Maximo log in screen.

Maximo 7.5 log in screen

Navigate to the following directory
C:\ibm\WebSphere\AppServer\profiles\ctgAppSrv01\installedApps\ctgCell01\MAXIMO.ear\maximouiweb.war\webclient\login\images
and but a new image with the same name as the orignal ones (ge_login_bkgnd.png and ge_login_bkgnd_ev.png) prefer to have the same dimensions 2000 X 768 for the first and 1208 X 554 for the second.

The New ge_login_bkgnd.png
Refresh the log in page and yupps.

The New Maximo 7.5 login screen

You can make this your company photo and replace IBM logo with yours.

Join Amulyam:

http://www.amulyam.in/signup.do?id=d322ff51-6d8c-421f-8e89-12d1f2268b80

Maximo Integration Framework Tutorial (Flat-file export and import)

Maximo Integration Framework Tutorial (Flat-file export and import)

Here we will configure Maximo IF (Integration Framework) to export the data and we will load a flat file (coma delimiter) with our data in Maximo (uploading the data in Maximo).

First we Go To > Integration module > External Systems.

Select EXTSYS1 from the List tab and from Select Action menu select Duplicate External System.
This new External System will be our playgroup we can do any thing with it and if thing gone wrong we can delete it and duplicate another one.







Then in the System text box put EXTSYS0 and Enable it from the check box on the other side.

In the Server where Maximo is installed create a folder where the exported files will go in my case it was a Windows Server 2003 and the path was C:\ibm\MIF.

Back at Maximo Go To > System Configuration module > Platform Configuration > System Properties.
Filter on int.globaldir now change the Global Value to C:\ibm\MIF Save then check the box on the far left of the screen and do a Live Refresh (red arrow), click OK.

It should look like this.


Now Go To > System Configuration module > Platform Configuration > Cron Task Setup.
Filter on flat and select FLATFILECONSUMER from the List tab.




Create a new Cron Task Instance by clicking the New Row command button set the Schedule to Every 30 Second(s) from the select value calender Icon.
Then check the Active box as seen in the snapshot below then Save.








Filter again on jms and select JMSQSEQCONSUMER from the List tab.
Then check the Active box in both instance as seen in the snapshot below then Save.








Now Go To > Integration module > Object Structure.
Create New Object Structure and name it MXJOBPLAN don't forget to select INTEGRATION in the Consumed By text box.
Then click the New Row button and select JOBPLAN as the Object from its select value message box.


Click the New Row button again and select JOBTASK this time as the Object from its select value message box.
Don't forget to select JOBPLAN as the Parent Object and JOBTASK as the Relationship.

Now for our newly created Object Structure be able to export its data as a Flat-file (CSV) we must tell it to Support Flat Structure from the check box marked in the snapshot below and Save.


As you can see there is an Alias Conflict which tell us that some of our Objects have Fields with the same name so to fix that we will select ADD/Modify Alias from the Select Action menu.
Then add a prefix (JP_) to the Fields ALIASNAME that is marked as DUPLICATED and click OK.



Now if should look like this.


Now we have an Object Structure MXJOBPLAN with with no Alias Conflict.

Next we Go To > Integration > Enterprise Services (This is the name the Maximo give to In-pound data configuration) and Create New Enterprise Service and name it MXJOBPLANint then assign it to MXJOBPLAN Object Structure.

Again Go To > Integration > Publish Channel (Out-pound data) Create New and name it MXJOBPLANint then assign it to MXJOBPLAN Object Structure.

Back to the External System where we will add the newly created Publish Channel from New Row then Select Value select MXJOBPLANint .








Don't forget to make the End Point as MXFLATFILE and Enable it from the check box.





Let's try to run a Data Export command button and see what we get.


In our path we created earlier C:\ibm\MIF we will find a new folder named flatfiles and in it we will find our output file.


If you opened it with a simple text editor like Notepad ++ you will see the data in a coma delimiter format (csv) you can now rename it as a .csv and open it with MS Excel edit it save it and re-upload it in Maximo.


As for in-bound integration.
First we enable the integration user in Maximo MXINTADM, from Go To > Security > Users then Filter on mxin select MXINTADM.




Notice that MXINTADM is ACTIVE as a Person but INACTIVE as a user so from the top Toolbar select Change Status set the New Status as Active.
OK and Save.










Now for the Enterprise Services from New Row then Select Value select MXJOBPLANint and Enable it from the check box.





Then click the Data Import button select Flat File and check Import Preview to make it a dry run (test with no actual data uploaded).

If our dry run was a success,


Try it for real.


and yippi.

Your data now is in Maximo congratulation.