Windchill Customization
Day 04
1
Takeaway
At the end of this session you should be able to
Windchill Data Model
Services
Preference Management
Object Initialization Rules
22
Windchill Data Model
Modelled Objects
Windchill manages many types of business and administrative concepts. The concepts
are modeled as objects in Java and instances of those objects are stored in a database.
The Modeled Objects page provides information about all modeled objects on the current
system. It provides a report that lists all of the modeled objects, and then a link to a details
pages for each one. The detailed information pages can include information about the
meta data for the object, the persistance mapping between the Java object and a
database table, UML diagrams and links to Javadoc.
Use these pages to learn about the modeled objects, how they are related, and how they
are stored in the database.
Location: Navigator > Browser > Customization > Tools > Modeled Objects
The customization tab can be exposed by setting the site level preference ‘Client Customization’ to Yes
33
WTPart Package ([Link].)
The [Link] package provides a standard implementation of parts. A part is an item that can be produced or consumed,
such as, an engine, a bolt, or paint. Parts can be assembled to produce other parts; for example, the drive train of an
automobile can be thought of as a part composed of an engine, transmission, shaft, differential, and so on.
The part classes are implemented based on the pattern established for revision controlled objects in the [Link]
package. These classes, WTPartMaster and WTPart, provide concrete classes exhibiting the management
characteristics established in [Link] and add specifics for parts. The properties of a part are specified on the
WTpart class. Then, for normalization purposes, the sum of the properties are stored on the WTPartMaster.
Attributes are on either WTPartMaster or WTPart. The WTPartMaster, as a Mastered object, represents the part’s
identity. As such, "number" and "name" have been placed on it. The part’s number is the stamp the enterprise
recognizes and uses for tracking purposes. The name is the human-readable component. These properties of the part
are assigned carefully and rarely changed.
Attributes on WTPartMaster have the same value for all versions and iterations. If an attribute on the master changes
after several versions and iterations have been created, the change is reflected in all the versions and iterations.
The WTPart, as a Versioned and Workable object, undergoes change that is recorded in its versions and iterations as a
result of a check-out and check-in process. Attributes on WTPart can generally have different values for each process.
Attributes on WTPart can generally have different values for each iteration, so changes impact only one iteration.
44
WTDocument Package ([Link].)
The [Link] package provides a standard implementation of managed documents. The document implementation uses
the Master-Iteration design pattern detailed described previously. The objects shown, ( WTDocument &
WTDocumentMaster), actually implement a number of interfaces to acquire their behaviour. To see the full scope of
interfaces that are implemented by these two objects go to the Javadoc for [Link] and
[Link].
The document classes are implemented based on the pattern established for revision controlled objects in the
[Link] package. These classes, WTDocumentMaster and WTDocument, provide concrete classes exhibiting the
management characteristics established in [Link] and add specifics for documents. The properties of a
document are specified on the WTDocument class. Then, for normalization purposes, the sum of the properties are
stored on the WTDocumentMaster. More specifically, WTDocument implements Format ContentHolder to give it a
primary content item and multiple secondary content items.
Attributes are on either WTDocumentMaster or WTDocument. Attributes on WTDocumentMaster have the same value
for all versions and iterations. If an attribute on the master changes after several versions and iterations have been
created, the change is reflected in all the versions and iterations. Attributes on WTDocument can generally have
different values for each iteration, so changes impact only one iteration. This is why content holder is implemented on
Document Iteration.
55
Change Package (wt.change2
Change Issue
Change Item
WTChangeIssue
Modelling Approach
Change Request (aka ECR)
Each change WTChangeRequest2
management object Change Investigation
is modelled using a WTChangeInvestigation
three-tiered Analysis Activity
approach: interface, WTAnalysisActivity
Change Proposal
abstract class, and
WTChangeProposal
concrete class
Change Order (aka Change Notice
or ECN)
WTChangeOrder2
Change Activity (aka Change Task)
WTChangeActivity2
66
Services
Windchill services provide APIs and logic to manage modeled business objects.
They consist of:
An (optional) helper consisting of static fields and methods, including a static field (generally named service
or manager) referring to a service
A service interface consisting of remotely-invocable method declarations
A standard service which implements the service and is registered to run as a service in the Method Server.
77
Implementing the Services – Helper Class
[Link]
[Link]
package [Link];
import [Link];
/** Helpers are not instantiated and should consist of only static fields/methods **/
public final class myHelper {
/** Use the ServiceFactory to acquire an instance of the service. **/
public static final myService service = [Link]([Link]);
}
88
Implementing the Services – ServiceClass
[Link]
[Link]
package [Link];
import [Link];
import [Link];
/** RemoteInterface annotation is required for all service interfaces **/
@RemoteInterface
public interface myService {
/** All interface methods are callable via RMI and must throw WTException **/
WTPart createPartByName(final String name) throws WTException;
}
99
Implementing the Services – StandardService Class
[Link] package [Link];
import [Link];
[Link] import [Link];
import [Link];
import [Link];
import [Link];
/** service must extend StandardManager, implement service interface **/
public class StandardmyService extends StandardManager implements myService {
/** MethodServer refectively calls this API during startup **/
public static StandardmyService newStandardmyService() throws WTException {
final StandardmyService instance = new StandardmyService();
[Link]();
return instance;
}
@Override
public WTPart createPartByName(final String name) throws WTException {
WTPart wtpart = [Link]();
try {
[Link](name);
}
catch (WTPropertyVetoException wtpve) {
throw new WTException(wtpve);
}
return (WTPart) [Link](wtpart);
}
}
10
10
Implementing the Services – Test Service
The service must be registered in [Link]; the number NNNN must be unique so as
not to replace an existing service. Note that changes to [Link] must be propagated
using xconfmanager. All customization services must be registered in [Link].
<Property name="[Link].99999“ targetFile="codebase/[Link]“
value="[Link]/[Link]"/>
Persisting WTPart with service
wtpart = [Link](’test’)
11
11
Preference Framework
Preferences are set through the Windchill user interface and do not require a server restart. They
control application behaviour. Preferences can be implemented on different levels of detail.
Preferences can be configured to control the whole Windchill installation, or can be used more
narrowly to control an organization’s or an application container’s (e.g. Product, Library), or a
The Preferences Framework is based on the principle that a unique preference consists of the
following attributes:
Parent Node (or root node if at the top of the hierarchy)
Preference Node (usually associated as a group of similar preferences)
Preference Key
Together these attributes form a unique key structure of parent/node/key. Thisunique key structure
will be referred to as the fully qualified preference key. To separate individual user and group
preferences for the same fully qualified preference key, a context is applied to the preference.
specific user’s setup.
12
12
Configuring Windchill Preferences
Preference categories are defined via XML load files to define the following attributes
Unique preference category name
Unique name string to identify the preference category
Parent Node
Name of the parent node in the preference hierarchy
Display name
The display name for the preference category that will be visible in the UI, localized using
RbInfo file
Description
The description for the preference category that will be visible in the UI, localized using RbInfo
file
13
13
Configuring Windchill Preferences
Preferences are defined via XML load files to define the following attributes
Unique preference name
Unique name string to identify the preference
Visibility
Defines the preference context, (SITE, ORGANIZATION, CONTAINER or USER)
Preference category
The category in which the new preference will be visible in the Preference management UI.
Display name
The display name for the preference that will be visible in the UI, localized using RbInfo file
Description
The description for the preference that will be visible in the UI, localized using RbInfo file
Long description
The long description for the preference that will be visible in the UI, localized using RbInfo file
Default Value
Default value for preference
Handler
Handler to define preference type
14
14
Exercise : Creating a Preference
The creation of a preference is done through an XML load file. When creating a preference the following pieces of
information need to be determined:
Unique preference name
Visibility: if the preference will appear in the preference manger UI and visible at what contexts: SITE, ORGANIZATION,
CONTAINER or USER.
Preference category: The category the new preference will appear under inthe Preference Management utility.
Display name: This is the Name column in the Preference Management utility – string in the form <RBINFO>:< RBINFO key>
Description: This is the Description column in the Preference Management utility – string in the form:
<RBINFO>:<RBINFO key>
Long Description: This description is displayed in the Edit Preference UI, gives a more detailed description including the
expected values.
string in the form <RBINFO>:<RBINFO key>
Default value
Value header
15
15
Exercise : Creating a Preference
In the example below, we will create a new preference named
/com/mycompany/MyNewPreference along with an associated preference
category to appear in the Preference Manager UI.
1 . Create a resource bundle for labels used for your new preference. Labels are
needed for display name and description of preference category which the new
preference will be visible under in Preference Management UI. Labels are also needed
for the display name, description and long description of your preference. Create the
file [Link] in package [Link]. In this
example, this file would be added to the <Windchill>/src/mycompany/pref directory.
16
16
Exercise : [Link]
package [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
@RBUUID("[Link]")
public final class mycompanyPreferenceResource extends WTListResourceBundle {
[Link]=[Link]
[Link]=true
[Link]=false
# Preference Category labels
[Link]=Training
[Link]=Preference Category for mycustom preferences.
# Preference Definition labels
[Link]=Training My Preference /com/mycompany/MyNewPreference
[Link]=Training My Preference Demo Description of preference /com/mycompany/MyNewPreference.
[Link]=Training My Preference Demo Long description of preference /com/mycompany/MyNewPreference.
}
17
17
Exercise : compile resource file
2. Build the resource bundle by executing the following command from a
windchill shell: ResourceBuild [Link]
3. Restart the servlet engine and the MethodServer.
4. Create Preference load file: [Link]. It will contain a definition for the new
preference category and new preference definition.
18
18
Exercise : preference xml
[Link]
<?xml version="1.0"?><!DOCTYPE NmLoader SYSTEM "[Link]">
<NmLoader>
<csvPreferenceCategory handler="[Link]">
<csvname>CUSTOM_PREFERENCE_CATEGORY</csvname>
<csvparentName></csvparentName>
<csvdisplayName>[Link]:[Link]</csvdisplayName>
<csvdescription>[Link]:[Link]</csvdescription>
</csvPreferenceCategory>
<csvPreferenceDefinition handler="[Link]">
<csvname>/com/mycompany/MyNewPreference</csvname>
<csvvisibility>USER</csvvisibility>
<csvcategoryName>CUSTOM_PREFERENCE_CATEGORY</csvcategoryName>
<csvdisplayName>[Link]:[Link]</csvdisplayName>
<csvdescription>[Link]:[Link]</csvdescription>
<csvlongDescription>[Link]:[Link]</csvlongDescription>
<csvdefaultValue>Default Value</csvdefaultValue>
<csvhandler>[Link]</csvhandler>
</csvPreferenceDefinition>
<csvLinkPreferenceClientDefinition handler="[Link]">
<csvname>/com/mycompany/MyNewPreference</csvname>
<csvclientName>WINDCHILL</csvclientName>
</csvLinkPreferenceClientDefinition>
</NmLoader>
19
19
Exercise : Loading preference xml and test it
5. Load the preference category and preference definition using the following
command:
windchill [Link] -d <fullpath>/[Link]
20
20
Customizing Object Initialization Rules [OIR]
Object initialization rules provide significant flexibility in adapting a Windchill system
to a specific customer’s environment and busines
A business analyst can set up rules that tell the system how to initialize newly
created objects.
For example, the business analyst can set the system up to number parts according
to the company’s part numbering policies (e.g. auto-number). The business analyst
may also set the system up to require the user to enter a manual number, or
alternatively, set the system up so that if the user does not enter a number, the
system will assign ones process needs.
21
21
Customizing Object Initialization Rules [OIR]
Windchill provides a set of XML driven ‘Object Initialisation Rules’, which can be configured to provide initial values for
common object attributes e.g. Number, Lifecycle Template etc. This configuration utility is detailed in the Windchill
Business Administration guide and is implemented using a series of OOTB rule algorithms.
Custom algorithms can also be created using the Java RuleAlgorithm interface upon which all OOTB algorithms have
been built
The following steps should be completed to create a custom algorithm:
Create a custom Java class that implements [Link]
Override the calculate method to implement the business logic required to implement the custom rule
String <Arg></Arg> values defined in the OIR are passed into RuleAlgorithm calculate method as an
Object Array. These arguments can then be used when defining the required business logic.
In the example OIR below, the NumberGenerator class uses the <Arg> parameter to determine the number sequence
to use when generating an object number.
<AttrValue id="number" algorithm="[Link].
NumberGenerator" ignore="false" force="false" final="false">
<Arg>{GEN:[Link]:WTDOCUMENTID_seq:6:0}</Arg></AttrValue>
22
22
OIR relationship with Objects
23
23
Customize OIR
Generate Document number as required DOC-1234-567
1. Implement a custom java class which implements RuleAlgorithm
2. Update the Site Doc OIR to implement the change
24
24
Exercise
package [Link];
import [Link];
import [Link];
import [Link];
import [Link];
public final class customDocNumberGenerator implements RuleAlgorithm {
private static final String RULE_RESOURCE ="[Link]";
public Object calculate(Object[] args, [Link] wTCont2) throws [Link] {
for(int i = 0; i < [Link]; i++)
if (args[i] == null) throw new
InvalidAlgorithmArgumentException(RULE_RESOURCE,ruleResource.NULL_ARG,new Object[] {i +1});
return formatNumber([Link](args));
}
private Object formatNumber(String number){
String formattedNumber = [Link](0,8) + "~"
+ [Link](8,12) + "~"
+ [Link](12,14);
return formattedNumber;
}
}
25
25
Exercise
Update the Site Document OIR
<!-- set the number to a generated number [Link]-->
<AttrValue id="number" algorithm="[Link]">
<Arg>DOC-</Arg>
<Arg>{GEN:[Link]:WTDOCUMENTID_seq:10:0}</Arg>
</AttrValue>
Create a New Document and test that the changes have been implemented
correctly.
26
26
