Plug-In Packages

Plug-In packages are similar to integration packages in that they are exportable and importable collections of information. By enabling the plug-in extension on a job, IFS/Asset Information Integration Manager^TM is able to support the conversion of integration packages to and from the format of the plug-in selected on a particular job. The asset information contained by the plug-in package can then be viewed and edited in the plug-in application.

Excel Plug-In Package

IFS/Asset Information Integration Manager at present provides an Excel Plug-In named Basic for Microsoft Excel that enables data to be converted to and from MS Excel. Limitations of this plug-in are as follows:

• The maximum number of rows in Excel is 65536. If each object selected for export in the outbound plug-in package has an object specification of 50 technical attributes the maximum number of this object that could be exported is 1310 objects (65536/50=1310).
• Sheet and column names created by the program should not be changed.

Once a plug-in package has been exported it is possible, to open and view this in the Excel application. Once the plug-in package is opened, the mandatory fields can be easily identified as those columns with an asterisk (*) at the end of the header text.

On occassion, an export would have been performed where a business object has relations to another business object. e.g. technical classes which are related to object classes. The object classes are soft relations for the technical class and may not be exported. These records will then appear in red in the plug-in package.

Outbound Plug-In Package

The outbound plug-in package is essentially the exported integration package in xml format that we select to convert to the format of the plug-in selected on a job. On exporting the plug-in package, a file for the job is created in the file location of the export root path where it can be viewed and consequently edited by the addition, deletion or modification of records. Every time a plug-in package on a job is exported, it replaces any existing plug-in package exported on that particular job.

Editing Plug-In Packages

Once a plug-in package is available it is possible to add, modify and delete records as long as the consistency of the business logic is maintained. The Asset Information Schema XML that can be viewed on the IFS/Asset Information Integration Manager tool serves as a guide to modify values on a record by stipulating the type of data (field type), maximum number of characters in a field, mandatory fields and other important field properties.

Business objects could be defined as new in a plug-in package simply by just entering necessary data like IDs, classes, and descriptions. However if you want to define a new document, this will require both document issue and a document title record to be added. Defining the document issue record alone will create an inconsistency. Another situation that creates inconsistency is when defining a document, object or a design part in the plug-in package with a class that is nonexistent in the Asset Data Management database.

Some special considerations when defining the most common business objects in a plug-in package are as follows:

• Object - An object can be defined by entering a few mandatory values for Object ID where the Object ID represents the combination of KeyA and KeyA01 to KeyA10.
  
  Business objects where Objects are involved in plug-in package are not converted to an integration package if a record for Plant does not exist. A recommended work around to get records for Plant, without exporting any objects is by selecting a value for the plant on the export job, entering a dummy value for the object ID which is a object ID that does not exist in the database, exporting the integration package and converting to a plug-in package.
   
• Object with a Technical Specification – An object with its specification can be defined but it requires some knowledge about how its data structure is built up and also some accuracy when entering new values. Object, ObjectTechSpec and ObjectSpecification are the business objects needed in order to define a new object and its specification. ObjectSpecification contains the actual attributes and its values and ObjectTechSpec is needed in order to connect the object with the specification.'

A good recommendation is to copy an existing object’s specification and after that simply change the Object IDs. The following describes briefly how this could be done:

Object – Define a new record for the object as described above.

ObjectSpecification – Copy an existing object’s specification and change the Object ID. Also modify attribute values as required for the new object. Attribute values are found in columns ValueText and ValueNumber.

ObjectTechSpec – Enter the Object ID and its corresponding Technical Specification ID.

• Design Part – A design part can be defined by entering a few mandatory values for Class, Version, Unit Of Measure and Design Part ID where the Design Part ID represents the combination of KeyA and KeyA01 to KeyA5.
  
  Business objects where Design Parts are involved in a plug-in package are not converted to an integration package if at least one record for Standard, UnitOfMeasure and BaseUnit does not exist. A recommended work around to get records for Standard, UnitOfMeasure and BaseUnit into the a plug-in package without exporting any design parts is by selecting a value for the standard on the export job, entering a dummy value for the design part ID which is a design part ID that does not exists in the database, exporting the integration package and converting to a plug-in package.

• Design Part with Technical Specification - The procedure for defining a new design part with it's specification is exactly the same as for objects. The only difference is that design parts and its specification are composed of three different business objects; DesignPart, DesignPartTechSpec and DesignPartSpecification.

• Document - A document can be defined by entering the following mandatory fields for Document Title, Document Issue and File:

  DocumentTitle: Class, Number, Title.

  DocumentIssue: Class, Number, Sheet, Revision

  Files: Class, Number, Sheet, Revision, Name, Path

The actual document file must be placed in AIIM’s export root path and in the sub folder defined by the file path on the new document.

Note: If dates and times are required to be added for Document Issue and Document Title on a plug-in package, they need to adhere to the ISO Date and Time Format which reads YYYY-MM-DD hh:mm:ss.

• Object Relations like Function, Location, Design Part, Pipe, Process, Loop, Object To/From– An object relation can be defined by entering the object IDs for the target and source object, where the target is the same as the parent object and source is the same as the child object. An object relation to a design part can be defined by entering the object and design part IDs, where the target is the design part and the source is the object. An object relation could only be established during the import to the database if source and target objects exist in the package or if they already exist in the database.
   
• Document Object Connections - A document relation can be defined by entering values for DocumentIssue and Object ID. Values for DocumentIssue should be entered exactly in the following format: Class, Number, Sheet, Revision.
   
• Document Design Part Connections - A document’s relation to a design part can be defined by entering values for DocumentIssue and Design Part ID. Values for DocumentIssue should be entered exactly in the following format: Class, Number, Sheet, Revision.
   
• Object Bill of Material - An object’s bill of material list can be defined by entering the object ID, design part IDs, SparePartQuantity and PurchaseQuantity.

Note: Refer to the Manage Plug-In Exercise of the Asset Information Integration Management course within the Asset Design Training Material for detailed examples of how to edit records on a plug-in package. 

Inbound Plug-In Package

The inbound plug-in package is essentially the exported and modified asset information file of a particular job that we select to convert to an integration package. On importing the plug-in package, an import integration package is created in the file location of the import root path. Every time a plug-in package on a job is imported, it replaces any existing integration package created by the import of the plug-in package on that particular job. It is recommended to analyze the converted plug-in package before import in order to find missing values for mandatory fields.