Teamcenter Active Workspace Search Indexing: Architecture, Types, Utilities & Solr Integration

Teamcenter PLM · Pillar 1 — Practitioner Insights

Teamcenter Active Workspace Search Indexing: Architecture, Types, Utilities & Solr Integration

A comprehensive technical guide to how Teamcenter indexes product data for global search in Active Workspace — covering the Solr engine, TcFTSIndexer pipeline, synchronous and asynchronous indexing flows, and the utilities every administrator needs to know.

Active Workspace · Search & Indexing Level: Intermediate – Advanced Published by CTGT Innovations Inc. · April 2026

Contents

Overview· Indexing Components· Lucene & Inverted Index· Analyzers· TcFTSIndexer Pipeline· Indexing Types· File Content Indexing· Utilities Reference· Enabling Index for Custom Objects· Key Takeaways

Overview: Why Search Indexing Matters in Teamcenter

The global search capability in Teamcenter Active Workspace (AWC) is one of the most heavily used features in any production PLM environment. Engineers, programme managers, and procurement teams rely on it daily to locate parts, drawings, documents, and BOM structures. Yet for many administrators and implementation teams, the underlying indexing infrastructure remains a black box.

Understanding how Teamcenter indexes data — what components are involved, how the pipeline works, and what controls are available — is essential for anyone responsible for maintaining search performance, troubleshooting missing objects, or extending the index to cover custom business objects and properties.

This article walks through the complete Teamcenter search indexing stack: from the Apache Lucene library at the core, through the Solr search engine, into the TcFTSIndexer pipeline, and out to the utilities that keep it all running. It also covers the key differences between synchronous and asynchronous indexing flows, and practical guidance on enabling indexing for custom objects and file content.

Indexing Components

Teamcenter's search indexing stack has three core components: the Indexing Engine (Solr), the Indexer process (TcFTSIndexer), and optionally the Dispatcher for asynchronous file content indexing. Understanding the role of each is the starting point for any indexing-related work.

Indexing Engine: Apache Solr

Teamcenter uses Apache Solr as its enterprise search platform. Solr (Searching on Lucene w/Replication) is an open-source, Java-based search platform built on top of Apache Lucene. It stores the indexed Teamcenter data that powers global search within Active Workspace.

Selected and configured product data is indexed into Solr; not all data in Teamcenter is indexed by default.
The master product data always remains in the Teamcenter database — Solr holds only the index representations used for search.
When a user retrieves an object through search, the full object data is loaded from Teamcenter, not from Solr.

Three-tier indexing stack diagram: Teamcenter source to TcFTSIndexer pipeline to Apache Solr, with Dispatcher as parallel branch for async file content indexing — Architecture diagram showing the three-tier indexing stack: Teamcenter (source) → TcFTSIndexer (export pipeline) → Apache Solr (search index). Dispatcher path for asynchronous file content indexing shown as a parallel branch.

Indexer: TcFTSIndexer

The TcFTSIndexer (Teamcenter Full Text Search Indexer) is an SOA client that connects to Teamcenter, extracts product data, and loads it into Solr. It installs as a four-tier SOA client and manages all indexing processes.

Runs a sequential pipeline of Query, Export, Transform, and Load steps.
Manages the initial (full) indexing flow and subsequent synchronisation runs.
Can be customised to extract data from external systems and index it alongside Teamcenter data.
Installed in one of two modes: Standalone (for object data) or Dispatcher-based (for active content structures and file content).

Lucene & the Inverted Index

Apache Solr is built on Apache Lucene, which is an Information Retrieval (IR) library written in Java. Understanding how Lucene structures its index is directly useful for anyone tuning search performance or extending the schema.

What is Lucene?

A high-performance, full-featured search engine library entirely in Java.
Collects information — normally in the form of documents — and processes them to construct an index data structure that enables fast lookups.
Without an index, an information retrieval system would need to read through all data on every search query (brute-force scanning). Lucene's index structure eliminates this.
The core building block is the Inverted Index (also referred to as a postings file).

How the Inverted Index Works

A standard document database maps documents to the terms they contain — a "document-centric" structure. Lucene inverts this: it maps terms to the documents they appear in — a "term-centric" structure. This is the inverted index, and it is what makes full-text search fast.

The inverted index has two substructures:

Term dictionary — all terms extracted from the indexed documents, sorted alphabetically. Sorting allows binary search — locating a term is fast even across millions of entries.
Postings list — for each term, a list of all documents in which that term appears.

Inverted index structure diagram showing documents on the left, sorted term dictionary in the centre, and postings lists on the right — Diagram illustrating the inverted index structure: three example documents on the left (e.g. Part Rev A, Part Rev B, Document C), terms extracted into a sorted dictionary in the centre, and postings lists on the right showing which documents each term appears in.

Analyzers: How Text is Processed Before Indexing

Before text is added to Lucene's inverted index, it goes through a process called analysis. An Analyzer converts raw field text into index terms — the fundamental units that queries are matched against. The choice of analyzer directly affects what users can find and how.

Analysis consists of one or more operations applied in sequence: tokenization (splitting text into units), lowercasing (normalisation), stop word removal (discarding common words with little search value), and stemming (reducing words to their root form). The chunks produced are called tokens.

Example: How Analyzer Processes a Sentence

Consider the input: "Lucene is an amazing library for searching and indexing text."

Processing Step	Result
Tokenization	["Lucene", "is", "an", "amazing", "library", "for", "searching", "and", "indexing", "text"]
Lowercasing	["lucene", "is", "an", "amazing", "library", "for", "searching", "and", "indexing", "text"]
Stop Word Removal	["lucene", "amazing", "library", "searching", "indexing", "text"]
Stemming	["lucene", "amazing", "library", "search", "index", "text"]

Built-in Analyzer Types

Standard Analyzer

General Purpose

The most commonly used analyzer. Applies the Standard Tokenizer, removes common English stop words, and lowercases all tokens. Suitable for most PLM metadata fields where standard English text search is required.

Input: "Lucene is awesome!" → Tokens: ["lucene", "awesome"]

Whitespace Analyzer

Exact Splitting

Splits text on whitespace only — no further filtering or processing. Case is preserved. Useful for fields where exact token boundaries matter and stop word removal would be incorrect (e.g., part number fields with structured naming conventions).

Input: "Lucene is awesome!" → Tokens: ["Lucene", "is", "awesome!"]

Keyword Analyzer

Exact Match

Treats the entire input as a single token — no splitting, no filtering. Used for exact-match scenarios such as item IDs, revision codes, or other identifiers where partial matching is undesirable.

Input: "PART-00123-RevA" → Token: ["PART-00123-RevA"]

Language Analyzer

Language-Specific

Tailored for specific languages. Applies stemming, stop word removal, and language-specific filters. For example, English Language Analyzer stems "searching" to "search" and "engines" to "engin". Relevant in multi-language PLM environments where descriptions or documentation are authored in non-English languages.

Custom Analyzer

Requires Configuration

A custom combination of tokenizers and filters assembled to meet specific customer requirements. For Teamcenter implementations with highly specialised naming conventions or proprietary classification terminology, a custom analyzer gives the most control over how those terms are indexed and matched.

The TcFTSIndexer Pipeline: Types, Flows, and Steps

The TcFTSIndexer is structured around three hierarchical concepts: Types, Flows, and Steps. Understanding this hierarchy is essential for customisation, troubleshooting, and scheduling.

Types

A Type represents a category of integration within TcFTSIndexer — for example, object data (ObjData) and structure data. Each type contains one or more flows.

Flows

A Flow represents a supported operation for a given type. The ObjData type includes flows such as index, sync, clear, and recover. Flows contain a sequence of steps that run in order.

Steps

A Step contains the method logic for a specific stage of the pipeline. Each step has defined inputs and outputs — the output of one step becomes the input of the next.

Three step types exist:

Simple step — processes input and passes output to the next step.
Split step — splits a large input list into parallel batches, each processed by a separate simple step.
Aggregate step — waits for all split step instances to complete and combines their outputs before passing to the next step.

ObjData index flow diagram showing four sequential steps: Query, TIE Export, Transform, and Solr Load with output labels between each step — Flow diagram for the ObjData index flow: four sequential steps — Query → TIE Export → Transform → Solr Load — with arrows between each step and brief labels describing the output of each (UID list, TC XML file, Solr XML file, committed index).

The ObjData Index Flow in Detail

The standard object data index flow runs the following steps in sequence:

Step	What Happens	Output
Query	TcFTSIndexer connects to Teamcenter, performs initial validation, spawns a thread, retrieves a list of UIDs to be indexed.	UID list file
TIE Export	Reads the UID file, chunks data into manageable batches, calls TIE export via the Pool Manager.	Teamcenter XML file
Transform	Converts the TC XML to Solr input XML format; injects security read expressions; identifies dataset objects for file content indexing.	Solr input XML file
Solr Load	Loads the Solr input XML into the Solr index; confirms export with the Server Manager.	Committed index data in Solr

Synchronous vs Asynchronous Indexing

Teamcenter supports two indexing flows for object data and file contents: synchronous and asynchronous. The choice between them has a direct impact on infrastructure load, indexing latency, and scalability — particularly for environments with large CAD datasets.

Synchronous Indexing

Simpler Setup

In synchronous indexing, TcFTSIndexer indexes both object metadata and file contents together in a single sequential flow. All four steps — Query, TIE Export, Transform, and Solr Load — run in order, and file content processing happens within the same pipeline.

When to use synchronous indexing:

File content indexing is not required, or only a small number of files need to be indexed.
Hardware resources are constrained — the synchronous flow has lower infrastructure overhead.
Simpler environments where operational complexity should be minimised.

Asynchronous Indexing

Scalable for CAD-Heavy Environments

In asynchronous indexing, file content is indexed separately from object metadata. The Dispatcher manages file content indexing tasks in parallel with object metadata indexing. Metadata from non-dataset objects is always indexed synchronously and becomes searchable while file content indexing completes in the background.

The asynchronous flow works as follows after the Transform step identifies dataset objects:

Datasets are grouped by type and submitted to the Dispatcher as DispatcherRequest objects.
The Scheduler routes requests to file content indexers via the Dispatcher Module.
Each file content indexer downloads the relevant files and extracts their contents using the appropriate extractor for the dataset type.
Extracted content is merged with metadata in Solr; Teamcenter is updated with the indexing status.

When to use asynchronous indexing:

CAD file content needs to be indexed (NX, CATIA, Creo files etc.).
You need to separate metadata and file content indexing to balance load.
Large file volumes would cause unacceptable wait times in a synchronous flow.
Dispatcher infrastructure is already in place for other services.

Side-by-side comparison of synchronous indexing as a single linear pipeline versus asynchronous indexing with Dispatcher parallel branch, both converging at Solr — Side-by-side comparison diagram: left column shows synchronous flow as a single linear pipeline; right column shows asynchronous flow with Dispatcher handling file content in a parallel branch, both converging at Solr.

File Content Indexing

File content indexing enables users to search not just object metadata but the actual text content within attached files — product specifications, analysis reports, technical documentation, and in some cases CAD files. Objects without associated datasets are always indexed using a synchronous process. For datasets, you choose synchronous or asynchronous during installation.

Key Preferences for File Content Indexing

Three site-level preferences control file content indexing behaviour:

Preference	Purpose	Scope
`AWS_FullTextSearch_Index_Dataset_File_Content`	Enables or disables file content indexing for full-text search globally.	Site
`AW_Indexable_File_Extensions`	Specifies which file extensions are indexed. Adjust to match the file types in your environment (e.g. `.txt, .doc, .pdf, .prt, .dft`).	Site
`AWS_Search_Enable_Snippets`	Enables contextual snippets in search results so users can see where their search term appears within a file.	Site

After configuring these preferences, restart the Pool Server and Solr process before running a full index to ensure the new settings take effect.

Indexing Utilities Reference

Teamcenter provides a set of command-line utilities for managing and maintaining the search index. Familiarity with these tools is essential for day-to-day administration and for resolving indexing issues in production environments.

TcSchemaToSolrSchemaTransform

Schema Management

Converts the Teamcenter data model schema to the Solr schema. This utility runs automatically when data model changes are deployed via TEM (Teamcenter Environment Manager). In some older TC versions, it must be run manually after BMIDE deployment.

call %SOLR_HOME%\TcSchemaToSolrSchemaTransform %TC_DATA%\ftsi\solr_schema_files

awindexerutil

Delta Updates — No Downtime

Marks objects for re-indexing without running a full index flow. The utility flags changed objects so they are picked up in the next synchronisation batch, enabling index updates without downtime or a full re-index cycle. Also supports -delta mode to handle changes since the last completed synchronisation, and processes data model type/property additions or removals.

Run from TC_ROOT\bin (or TC_BIN).

awindexerutil -u=user-id -p=password -g=group [-refresh] [-delta [-dryrun] [-daterange]] -h

runTcFTSIndexer

Core Indexer Execution

The primary command for running indexing flows against the Solr engine. Run from the FTS_INDEXER_HOME directory (typically TC_ROOT\TcFTSIndexer\bin).

runTcFTSIndexer -debug -maxconnections -status -stop -service -shutdown -task=[objdata|multisite|structure|fourgd]:flow-action -h

Common task invocations:

-task=objdata:index — full object data index
-task=objdata:sync — incremental synchronisation
-task=objdata:indexsyncfailures — re-index failed objects

aw_search_config_manager

Advanced — File Content Mapping

Manages mapping configurations for asynchronous file content indexing. Use this utility when customising how data extracted from non-standard files (such as CAD datasets) is indexed into Solr. Supports import, export, remove, and list operations on mapping configurations.

aw_search_config_manager -u=user-ID {-p=password | -pf=password-file} -g=group
  [-import -dir=config-directory]
  [-export -config_id=config-id -output=output-file-path]
  [-remove -config_id=config-id]
  [-list]
  [-h]

solrCloudSetUp

Migration Utility

Used when migrating to SolrCloud from a standalone Solr installation. Sets up ZooKeeper, creates configsets and collections, configures basic authentication, and migrates existing data — allowing migration without requiring a full re-index from Teamcenter.

solr-version.solrCloudSetUp.bat -migrate -u=username -p=password -copy_data

Enabling Indexing for Custom Business Objects and Properties

Out of the box, only a subset of Teamcenter's business objects and properties are indexed. For custom objects and properties created in BMIDE, indexing must be explicitly enabled. The process is straightforward but must be completed in the correct sequence.

Steps to Enable Indexing for a Custom Object or Property

In BMIDE, select the custom business object. Set the business object constant Awp0SearchIsIndexed to true.
For each custom property on that object that should be searchable, select the property and set the property constant Awp0SearchIsIndexed to true.
Deploy the data model changes via TEM. This automatically triggers TcSchemaToSolrSchemaTransform to regenerate the Solr schema. In older TC versions, run this utility manually after deployment.
Run runTcFTSIndexer with the objdata:index or objdata:sync task to index the new objects and properties.
Log in to Active Workspace and verify that the new objects and properties are returned in global search results.

A Common Misconfiguration to Watch For

One frequently encountered issue during custom object indexing: the property constant Awp0SearchIsIndexed is set to true on a property, but the business object constant of the same name remains false on the parent object. The property will not be indexed in this state. Both constants must be true — object and property level. Always verify both when troubleshooting missing properties in search results.

BMIDE business object constants panel for a custom object with Awp0SearchIsIndexed constant highlighted and set to true — BMIDE screenshot showing the business object constants panel for a custom object, with the Awp0SearchIsIndexed constant highlighted and set to true.

Key Takeaways

Solr holds the index, not the data. Master product data always resides in Teamcenter. Solr stores only indexed representations for fast search. Objects returned by search are loaded from TC, not from Solr.
Choose your indexing flow based on environment complexity. Synchronous indexing is simpler and lower-overhead. Asynchronous indexing scales better for CAD-heavy environments where file content indexing is required and Dispatcher is already in use.
The Analyzer choice shapes what users can find. Standard Analyzer works for most metadata. Keyword Analyzer is the right choice for item IDs and structured part numbers where partial matching would produce incorrect results.
Both object and property constants must be set for indexing to work. Setting Awp0SearchIsIndexed = true on a property while leaving it false on the parent business object will silently prevent indexing. This is one of the most common root causes of missing properties in AWC search.
awindexerutil is your best friend for production index maintenance. It enables targeted, incremental index updates without downtime — use it after BMIDE deployments, data corrections, or bulk object changes rather than running full index flows unnecessarily.
After changing file content indexing preferences, always restart before running a full index. Pool Server and Solr must both be restarted for preference changes to take effect.

About CTGT Innovations Inc.

CTGT Innovations is a Siemens Elite Partner and PLM implementation firm with deep Teamcenter expertise across automotive, aerospace, and industrial manufacturing. We deliver Teamcenter implementation, upgrade, migration, and managed services engagements globally, with delivery teams in Pune, Toronto, and Munich.

For enquiries about Teamcenter Active Workspace configuration, search indexing implementation, or upgrade services, visit www.ctgti.com

Siemens Elite Partner TISAX Certified ISO 9001 Certified