How to install fsc in Teamcenter?

FSC can be install by running "installfsc.bat" file.

"installfsc.bat" file is located at FSC folder of TC_ROOT.

Command to run  "installfsc.bat": Run below commands in command tc_commandprompt

installfsc %JAVA_HOME% %FSC_HOME% fscid

%JAVA_HOME% = JAVA path

%FSC_HOME% = FSC folder location

fscid = fscid

for example : c:\apps\Siemens\Teamcenter10\fsc>installfsc "C:\Program Files\Java\jre7"

"D:\apps\Siemens\Teamcenter10\fsc" FSC_SVI6W181_user1

fscid can be get from "configuration.xml" file which is located in install folder of TC_ROOT.

fscid can be get from "masterfsc.xml" file which is located in FSC folder of TC_ROOT.

NOTE:If space are there in JAVA_HOME and FSC_HOME location put in double quote.

Difference between HOT Deploy and COLD Deploy in BMIDE

 HOT Deploy

• Hot deploy can be done directly over the BMIDE.
• Hot deploy is only good for non-schema object change.
• Create custom business object, create custom properties, UOM, create LOVs, Create Rules etc. comes under non-schema.
• Hot deploy good for adding LOVs value, changing display name, adding some properties.
• Every time needs  to restart server manager when we make Hot deploy.

COLD Deploy

• Cold deploy can be done only by tem.
• Cold deploy used for both schema and non-schema changes.
• Create custom business object, create custom properties, UOM, create LOVs, Create Rules etc. comes under non-schema.
• Classes and Attribute comes under schema object.
• Every time needs  to restart server manager when we make Cold deploy.

What is Property Constant in BMIDE ?

Property Constant

Property constants is used to change the characteristics of business object properties.  

We can attach property constants to make properties enabled, modifiable, exportable, required, a stub property, visible, or to set the initial value etc. 

We can also create our own property constants to apply our own characteristics.

Property constants provide default values to business object properties. Because these constants are attached to properties.

How to make a property mandatory in BMIDE?

Select property of an Business Object from properties Tab, in the property constants tab, make Required  property constant value as True.

Display Rules

 Display Rules

Business object display rules determine the members of the organization who cannot view a business object type in menus in the Teamcenter user interface. The Display Rules editor displays the groups and roles that are not allowed to see the selected type of business object in menus. This rule is primarily used to hide business objects from creation (File→New) menus, thereby restricting those who can create the business object type.

Business object display rules can be applied to the following business objects and their children:

• Dataset

• Folder

• Form

• Item

 Note:

• Although users cannot create objects associated with restricted object types, they can view them and perform other operations, such as copying, modifying, or deleting the objects.

• Business object display rules are subject to the principles of group hierarchy and inheritance. Rules defined at the site level are inherited by all groups and roles within groups. Rules defined for a group are inherited by all subgroups, but rules applied to a subgroup do not affect the parent groups or other subgroups at the same level in the hierarchy (sibling groups). Rules applied to roles within groups apply to all users with that role, but do not affect other roles in the same group.

Deep copy rules

Deep Copy Rules 

Deep copy rules define whether objects belonging to a business object instance are copied when a user performs a save as or revise operation on that instance. Deep copy rules can be applied to any business object type and are inherited by children business object types.

Available actions to perform deep copy rules are :

CopyAsObject

Creates a new object of the same type as the related object and relates to the new revision. Objects created by this method are totally independent of the source object. Therefore, modifications to the new object are not reflected in the source object.

CopyAsReference

Creates a new relation between the new revision and the related object. Therefore, modifications performed on the copied object are propagated to the source object

NoCopy

Does not copy forward objects of the specified property type and relation.

Important Note:

Deep copy rules with high specificity have higher precedence than those with more general applicability. Four levels of specificity, and thus precedence, are possible:

Rule Level 1 {Target Business Object, Relation Type, Attached Business Object} - 1st highest precedence

Rule Level 2 {Target Business Object, Relation Type, Match All} - 2nd highest precedence

Rule Level 3 {Target Business Object, Match All, Attached Business Object} - 3rd highest precedence

Rule Level 4 {Target Business Object, Match All, Match All} - 4th highest precedence

At each level, a rule with a custom condition=true has higher precedence over a rule with

isTrue condition.

GRM rules(Generic Relationship Manager)

GRM rules (Generic Relationship Manager)

Generic Relationship Management (GRM) rules is used to apply constraints on the relationship between two business objects.

Using Generic Relationship Management (GRM) rules we can apply limit what objects can be pasted to other objects.

For example, if you do not want a certain type of object to have a specification relation to another type, you can set the cardinality to 0 to deny pasting of one type of object to another with the specification relation.

When you create a GRM rule, you select the primary business objects and secondary business objects for the relationship, the relationship they have to one another, and the constraints to be applied. 

Available relationships are children of the ImanRelation business object.

Cardinality : Determines the number of allowed occurrences of the primary object in relation to the secondary object, and of the secondary object in relation to the primary object.

When you create a GRM rule, type a number in the Primary Cardinality or Secondary Cardinality, allowed numbers are:

-1 or *                   =     Allow an unlimited number of relationships.

0                            =     Do not allow any relationships.

1, or 2, or 3, and so on    =    Allow the specified number of relationships.

Inheritance of GRM rules

The GRM rule applies for all children of the primary and secondary objects. However, rules defined for a sub-business object take precedence over the relation rules defined for a parent object.

For Example : 

If the ItemRevision business object is chosen as the primary object, and the DirectModel dataset is chosen as the secondary object, then all children of these objects that have the relationship inherit the rule.

Therefore, all instances of the children of ItemRevision that are related by the relation specified in the rule to any instance of children of DirectModel are subject to the constraints defined by the rule.