TASL Implementation

Business Requirements

BR1: Customer business needs the below item types for better data management.
TASLAbstarctItem -- TASLCode and QualityCode TASLAbstarctItem Revision
a) TASL_Part
b) TASL_Std_Part
c) TASL_Assembly
d) TASL_Sup_Part
What is an abstract item and when you will go for it?
a) Abstract item is the type of object that cannot be instantiated
b) We use it when need common characteristics
c) We cannot see abstract type in the UI

BR2: Below properties should be there on TASL Part Revision

- Material --> String
- Steel
- Aluminium
- Composite

- Security Classification --> String

- Plant Location --> String

- Model Type --> String

- Mfg Temp --> Double

- Inhouse? (YES|NO) --> Boolean

- Document ID --> String

- Customer Details (Customer name, Customer Address, Customer Mobile)

a) Customer Name: String
b) Customer Address: Long String
c) Customer Mobile: Int

Customer Name Address Mobile Location

- Perf Measurement - Name/Value

- Mfg Date :--> Date

- PI Constant

Property Constant:
BR3: Customer wants a property on TASL Part revision named PI Constant, with behaviour
a) User should not be able to alter (modify) the value
b) Property should have an initial value set already 3.14

BR4: Customer wants a property material to be set only once, the user should not be able to modify the
value
Hint: Modifiable

BR5: Customer wants a property to be used by some calculation internally and it should not be visible on
the UI
Hint: Visible

BR6: Customer wants during revise/save-as property plant location value should not get copied over
Hint: CopyFromOriginal
BR7: Customer wants all these a) properties to be searchable through global search and b) should be
available on the filter panel.
Hint: Awp0SearchCanFilter, Awp0SearchIsIndexed, Awp0SearchFilterPriority

--------------------------------------------------------------------
Run the following commands to synchronize BMIDE for Filter/Index in AWC
Generate Schema: (Required in case of hot deploy or live update)
bmide_generatetcplmxmlschema.bat -u=infodba -p=infodba -g=dba -dir="%TC_DATA%"
bmide_modeltool.bat -u=infodba -p=infodba -g=dba -tool=all -mode=upgrade -
target_dir="%TC_DATA%"

Merge Schema: %TC_ROOT%\solr-8.6.3\TcSchemaToSolrSchemaTransform.bat %TC_DATA%\ftsi\

solr_schema_files

Manage Solr Index:

Clear cache: %TC_ROOT%\TcFTSIndexer\bin\runTcFTSIndexer.bat -task=objdata:clear
Index: %TC_ROOT%\TcFTSIndexer\bin\runTcFTSIndexer.bat -task=objdata:index
Set indexing at regular intervals: "%TC_ROOT%\TcFTSIndexer\bin\runTcFTSIndexer.bat" -
task=objdata:sync –interval=30 (seconds == every 15 mins)
-----------------------------------------------------------------
BR7.1: Customer wants to combine the values of two properties “material” and “Plant Location” and
display in one property.
WeightInfo: Steel – 10 KG
Hint: ComplexProperty Constant
BR8: Customer wants security classification as a required property during creation of TASL part as well as
revise/save-as of TASL part revision.
Hint: CreateInput, SaveAsInput, ReviseInput

Property Formatter:
BR9: Customer wants "in-house" property value to be displayed as YES or NO for better user experience.
True | False
Are you going to manufacture part in house?
TRUE | FALSE –(property formater) YES | NO

BR10: Customer wants "manager name” to be displayed with Mr.

BR11: Customer wants "mfg temp" property to have degree centigrade

Business Object Constants:

BR12: Customer wants to restrict their user to uploading files having special character include $, #, !, and
&
Hint: Business object constant - Fnd0DatasetFileNameMaxLen=100

BR13: Customer wants the user to see the material property value in the header
Hint: Business Constant: DisplayName=$item_id+"/"+$item_revision_id+";"+$sequence_id+"-"+
$object_name+"-"+$t7Material
Property

BR14: Customer wants their user to be restricted to revise the TASL part revision provided there is
already two working revisions available.
(Solution: a) Set the BO constant (MaxAllowedWorkRevsForItemCopyRev) b) Add the extension-
checkLatestReleased)

Global Constant:
BR15: Customer wants user not to see more than 3 categories and 3 filter value
BR16: Customer wants the user should be able to create a structure using TASL Part Revision
Hint: Set the global constant Awb0SupportsStructure=Custom Item Revision

BR16.1: Customer wants the user should not be able to create data if the “security program” is not set in
the user session.
Hint: Set the global constant

------------------------------------------------------
LOV
------------------------------------------------------
LOVs: List of values (Pick list)
Why do we need to use LOVs?
• User efficiency (Save time) – improved user experience.
• Avoid unwanted value.
• Avoid mistakes.
What are those types of LOVS?
1) Classic LOV: List of static values stored in the data that get presented to the user for selection
2) Dynamic LOV: List of values that system has based on the dynamic query that get presented
to the user for selection
3) Batch LOV: List of values that we load to the system externally (using utility) that get
presented to the user for selection
BR17: There is a property on IR that control the data classification and user should select from only
defined values (not allowed to enter their own choice)
Control Classification (Exhaustive) - For Classification property
Secret
Top Secret
Super Secret

BR18: There is property on IR which hold material information and user can select from defined values
and also enter material name if it is not defined in the LOV
Material (Suggestive LOV) -- For material property on Part Revision
AL
Steel
Plastic

BR19: There is property on IR which user has to select the city of plant from the given hierachical tree
Plant List: (Cascading/Hierarchical LOV) - For Plant List property on Part Revision
India
- Chennai
 - Rajkot
China
- Bejing
- Shanghai

BR20: When user select the model in model type there respective partner
Interdependent LOV on properties: Model Type and Partner
Model Type:
TASL Wristwatch
- Richo
- Bosch
TASL Wallwatch
- TASL
- Behr

BR21: When user create the part there is property that hold the document ID and hence user has to
select that from the list of IDs (which is dynamically updating based on documents created in the system
that point of time)
Document ID: (Dynamic LOV) -- For Document Number Reference on Part Revision
- Document ID

BR22: Customer has business situation where they have to update the values of LOV constantly and
hence need to use batch LOV to update these values through utility (without downtime and without
BMIDE deployment)
• Large set of value to manage as pick list (LOV)
• Avoid BMIDE changes and hence avoid downtime on production server
Example LnT is project based company which need to work with different supplier every time new
projects comes, under this situation they need to constantly update the supplier name LOV that is
attached to supplier name property on IR

----------------------------------------------------------------------
Naming Rules
-------------------------------------------------------------------

BR23: TASL Part should have numbering scheme as below.

TASL-AAA001 --- TASL-ZZZ999
Hint:
Initial Number: TASL-AAA001 - (Offset by 3) – First Number TASL-AAA004
Step=2
 • TASL-AAA006
• TASL-AAA008
• TASL-AAA010

BR24: TASL Assembly should have numbering scheme as below

TASL-Asy-GroupID-0001 - TASL-Asy-GroupID-9999
Engg: TASL-Asy-ENGINEERING-0001

“TASL-Asy-${GROUP}"-nnnn

BR25: TASL Standard Part should have numbering scheme as below and it should depends user inputs

Location + Product Type + Department+0001

Example: PuneWristDesign0001
LocationLOV:Pune, Chennai
Product Type:WR, WW
Department:WFI, WFIU

Comb1: Pune+WR+WFI === NR1

Comb2: Chennai+WW+WFIU === NR2
Comb3: Pune+WW+WFIU == NR3
Hint:
Step1: Create subtype of fnd0baseIDGenerator
Step2: Add properties and corresponding LOVs
Step3: Create IPN
a) Define the condition(s)
b) Define the naming rule(s)
Step4: Attach the IPN to item_id
Step5: Update the stylsheet
Update the Std Part Create Stylesheet
<section title="Elec ID Configuration" titleKey="tc_xrt_IdGenInfo">
<property name="fnd0IdGenerator:e5Department" />
<property name="fnd0IdGenerator:e5Location" />
<property name="fnd0IdGenerator:e5ProductType" />

</section>
Example as shown below

BR26: TASL Part Revision ID numbering should be as below

TASL-AAA001/A1 - Development revision ID should starting with A1, A2, A3
TASL-AAA001/1 - Production revision ID should starting with 1,2,3,..
LOV based naming rule :
• What is naming rule in Teamcenter?
• When are you going to use it? (under what business situation (business requirements) you will
use it)
• How do you configure it?
• What benefits do you see here from naming rule?

22nd Nov
---------------------------------------------------------------------
Deep Copy Rule controls what should get carry forward to the new object during revise and save-as
operation.
-----------------------------------------------------------------------
BR27: Customer wants when user revise the TASL Part Revision then Text type of dataset which is
attached to the existing revision with relation IMAN_Specification should get copied over as reference.

BR28: Customer wants when user revise the TASL Part Revision then MS Word type of dataset which is
attached to the existing revision with relation IMAN reference should get copied over as (new) object.

BR29: Customer wants when user revise the TASL Part Revision then Direct Model type of dataset which
is attached to the existing revision with relation IMAN_rendering should not get copied over to the new
revision.

BR30: Customer wants when user revise the TASL Part Revision then Document Revision which is
attached to the existing revision with relation IMAN_specificaiton should not get copied over to the new
revision but it should use the latest revision from that document.
23 – Nov - 2023
---------------------------------------------------------------------
GRM
-----------------------------------------------------------------------
How many secondary objects of specific type can be attached with specific relation to the primary
object of specific type, is called secondary cardinality.
Example:
Primary object type: Sup Part Revision
Secondary Object Type= MS Word
Relation Object Type= Specification
Secondary cardinality is infinite: User can attach infinite number of MS world type of object to
Sup Part Revision

How many primary objects of specific type can be attached with specific relation to the secondary
object of specific type, is called primary cardinality.
Example:
Primary object type: Sup Part Revision
Secondary Object Type= pdf
Relation Object Type= Specification
Primary cardinality is infinite: User can attach infinite number of Sup Part Revision type of
object to pdf

BR31: Customer wants user should not be able to attach MS Word type of dataset to the TASL Sup Part
Revision using IMAN_Specification relation.

BR32: Customer wants the user should not be able to attach more than two TEXT types of the dataset to
the TASL Sup Part Revision using IMAN_Reference

BR33: Customer wants user should not be able to attach MS Excel to more than 2 TASL Sup Part Revision
using IMAN_Reference.
---------------------------------------------------------------------
Type Display Rule -- we used this to hide the object types such as Item / Item Revision from the
creation panel.
-----------------------------------------------------------------------
BR34: Customer wants user from Manufacturing Group should not be able to see "TASL Sup Part" for
creation.

BR35: Customer wants Mfg head from Manufacturing Group should see "TASL Assembly" for creation
but nobody from that mfg group see the "TASL Assembly"

24-11-2023
-----------------------------------------------------------------------
BMIDE Conditions helps us define the expression that returns true or false.
This condition we can in different configuration such naming rule, LOVs, display rule, GRM,
-----------------------------------------------------------------------
BR36: Customer wants naming rule so that when engineering creates an "TASL Auxiliary Part" they
should be able to get naming rule as Aux_Engg_NR-001 and when manufacturing creates a "TASL
Auxiliary Part" they should be able to get naming rule as Aux_Mfg_NR-001
BR37: Customer wants to allow Engineering Group Users to attach the MS Word type of dataset to " TASL
Auxlary Revision" and nobody else

BR38: Customer wants to different LOV values for material property on TASL Auxilary Revision

BR39: Customer wants LOV to be displayed for material only when owner of the data is equal to user
who logged into the system.

27-Nov-2023
-------------------------------------------------------------------------
Options:
------------------------------------------------------------------------
BR40: Customer wants note types such as "TASL Assembly Note" to be available on the BOM line to
capture additional information in context of assembly.

BR41: Customer wants to separate the occurrence in the BOM and hence want occurrence type such as
"TASL Consumable" and "TASL Std Part"
BR42: Customer wants purchase and service BOM view for their engineering assembly, so purchase &
service department can get the view of the assembly in which they are interested in.
Hint: Create purchase and service view

BR43: Customer wants status such "TASL Evaluated" and "TASL Released" for their TASL Part Revision
lifecycle

BR44: Customer wants unit of measure such "KG" and "GM" to use to measure components/parts.
Note: Teamcenter doesn’t any unit of measure OOTB

BR45: Customer wants to store and manage the AVI files in Teamcenter.
Note: Teamcenter doesn’t offer and also the dataset type OOTB

---------------------------------------------------------------
IRDC
---------------------------------------------------------------
BR46: Customers want default template file to be there when user create an TASL Spec Document
(Save user time in filling the information, consistency in the information, std document format for
business)
Doc0001
Doc0001/A
Spec.txt

Hint: IRDC
Step1:

Step2: Create a template (TEXT/word/ppt/xls..)

Step3: Create a dataset using above file

Step4: Release the IR and make sure dataset is also released

Step5: Create the custom document type (you can also use OOTB document type)

Step6: Create the IRDC

---------------------------------------------------------------
Extension (Extend the behaviour)
---------------------------------------------------------------
BR47: Customers want an "Information Form" to be created when user creates a TASL Auxilary Part
Hint:Extension (CreateObjects)
Step1: Custom form

Step2: Use the “Create Object” extension.

BR38: Customer want TASL Part should get automatically assigned on creation to the project/program
set in the user session
Hint:Extension(autoAssignToProject)

--------------------------------------------------------------------------------------------------------------------------------------
Hot Deployment
a) BMIDE
b) Recommended for development or test environment
c) Takes less time as it run lesser number of utilities
d) Downtime not required

TEM deployment
a) TEM
b) Recommended for production environment
c) Takes more time as it all the utilities that are required for deployment
d) Downtime required (because it stop services)
First time deploy: Need to browse the template project and deploy it

Second time deploy: Update the project that is already deployed, you need to select “update database
full model” and follow TEM screen

BR48: Customer is using production environment where 5k users are connected to the system, and they
have cadence of 3 month to deploy the solution, they have deployed the BMIDE project on last Sunday
by taking downtime, unfortunately the developer have missed adding LOV to the one property.
Under this situation nobody will allow to take the down again for this week. Another chance to add
missing property will come after 3 months. But business can not wait.
Hint: Live update
------------------------------------------------------------------
How BMIDE project get deployed in the database?
1) business_model_extractor - extract the data model from datase into XML format
model_db.xml
2) bmide_consolidator - consolidates all template.xmls in to model.xml
3) bmide_compartaor - compares the model_db.xml with model.xml and generate delta.xml
4) business_model_updater -update the database with delta.xml

When deployment fails usually?

Situation1: You have deployed the property and use it in the client, now in BMIDE you are reming and
then deploying.
Situation2: You have deployed some objects which has mandatory fields, UI didnt stop you do that, but
update fails

----------------------------------------------------------------