Team Center Services

Teamcenter® 2007

Teamcenter ServicesGuide

Publication NumberPLM00076 A

Proprietary and restricted rights notice

This software and related documentation are proprietary to UGS Corp.

© 2007 UGS Corp. All Rights Reserved.

All trademarks belong to their respective holders.

2 Teamcenter Services Guide PLM00076 A

Contents

Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Enable Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Start Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Teamcenter Services user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Configuration required for Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . 1-3

Introducing the Teamcenter Services framework . . . . . . . . . . . . . . . . . 2-1

What is SOA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Why Teamcenter Services is important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2What you can do with Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Teamcenter Services advantage for your organization . . . . . . . . . . . . . . . . . . 2-2Teamcenter Services framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Using Teamcenter Services framework components . . . . . . . . . . . . . . . 3-1

Establishing a Teamcenter session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Calling services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3Client data model components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5Handling errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7Creating object property policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9

Teamcenter Services organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Teamcenter System Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Teamcenter System Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3Teamcenter Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4Teamcenter Application Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9Teamcenter Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14Teamcenter Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19Teamcenter Application Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20

Performing common tasks using services . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Retrieving basic item information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Uploading and downloading persistent files . . . . . . . . . . . . . . . . . . . . . . . . . 5-3Importing and exporting data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1

Figures

3-1. Object property policy impact on performance . . . . . . . . . . . . . . . . . . . 3-12

PLM00076 A Teamcenter Services Guide 3

Contents

3-2. Object project policy effect on execution time . . . . . . . . . . . . . . . . . . . . 3-134-1. Teamcenter service functional organization . . . . . . . . . . . . . . . . . . . . . 4-1

4 Teamcenter Services Guide PLM00076 A

Chapter

1 Getting started

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Enable Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Start Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Teamcenter Services user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Configuration required for Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . 1-3Connecting a client application to the server . . . . . . . . . . . . . . . . . . . . . . 1-3Using client libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

PLM00076 A Teamcenter Services Guide

Chapter

1 Getting started

Teamcenter® uses a service-oriented architecture (SOA) as one means to providecustomers with the ability to quickly and easily develop task-specific clients, utilities,and system integrations using the power of the Teamcenter server. The TeamcenterServices operations are accessed through coarse-grained interfaces that minimizethe amount of network traffic needed to accomplish any specific task. As such,Teamcenter is ideal for applications that were previously impractical because of slownetwork speeds or limited network bandwidth.

Teamcenter Services ships with libraries and interfaces to build applications inJava™, C++, and .NET, giving you the flexibility to choose the technology that bestfits with your particular environment and standards. Teamcenter Services also shipswith WS-I compliant WSDL files for all operations, giving you further flexibility andthe confidence that comes with supporting open industry standards.

PrerequisitesThe following are required to use Teamcenter Services:

• Access to a Teamcenter 2007 (or later) server

• An application development environment used for Java, C++, or .NET softwaredevelopment

PLM00076 A Teamcenter Services Guide 1-1

Chapter 1 Getting started

Enable Teamcenter ServicesTeamcenter Services is an integral architectural component of all Teamcenter2007 and later servers, regardless of the deployment configuration (two-tier orfour-tier) selected. The language-specific client libraries you must import into yourdevelopment environment are available on the Teamcenter installation softwaredistribution image. Libraries are included for Java, C++, and, .NET, as well asWSDL interfaces. All Teamcenter Services WSDLs are compliant with the WS-IBasic Profile.

Although the Teamcenter 2007 and later servers include services interfaces in alldeployment configurations as mentioned above, the provided client libraries are notequally appropriate for use in all deployments. In particular, the C# libraries areonly available in four-tier (HTTP) deployments, while the Java and C++ librariessupport both two-tier (IIOP) and four-tier (HTTP) deployments. While WSDL itselfdoes not define a transport, HTTP is the most common and the only one supportedby Teamcenter Services.

Note

If you want to use the Teamcenter Services WSDL, you must install theoptional Teamcenter Services WSDL/SOAP Support module to the Web tierinstallation using the Teamcenter Web Application Manager.

For more details about Teamcenter deployment options and installation instructions,see the Installation on UNIX and Linux Servers Guide or the Installation onWindows Servers Guide.

Start Teamcenter ServicesTeamcenter Services is built right into the Teamcenter server and is an integral partof the Teamcenter 2007 and later architecture, so there is nothing specific that needsto be done to ensure that the Teamcenter Services interfaces are available for use.

Teamcenter Services user interfaceTeamcenter Services is a programming interface or API exposed to applicationdevelopers, rather than a program or application in and of itself, so it does nothave a user interface.

1-2 Teamcenter Services Guide PLM00076 A

Getting started

Configuration required for Teamcenter ServicesUsing the Teamcenter Services client libraries does not require any additionalconfiguration of the Teamcenter server.

Connecting a client application to the server

The Teamcenter server does not require any additional configuration to allow yourclient application to use Teamcenter Services. The only configuration required isin your client application to tell it how to connect to the Teamcenter server. This isdone with a host address using a specific format for each kind of deployment:

• Client libraries in four-tier deployments

http://server:port/app-name

• Client libraries in two-tier deployments

iiop://host:port/server-id

• WSDL/SOAP in four-tier deployments

http://server:port/app-name/services/service-port?wsdl

http://server:port/app-name/services/service-port

In the examples, replace variables with the following:

• server is the network name of the machine that the Teamcenter Web tier isexecuting on.

• port is the port number on the Teamcenter machine that is configured forcommunications.

For HTTP communications, this is the port number on the Web applicationserver. For example, if you are using WebLogic, the default value is 7001, or ifyou are using Apache Tomcat, the default value is 8080.

For IIOP communications, this is the port defined by the CORBA ORB Endpoint.

• host is the network name of the machine that the Teamcenter server is executingon.

• server-id is the CORBA ID of the Teamcenter server.

• app-name is the application name that the Teamcenter Web tier processes aredeployed under. The default value is tc, but may have been changed during theinstallation and configuration of the Teamcenter server software.

• service-port is the name of the Teamcenter Services operation being called. Theoptional URL query string wsdl returns the service WSDL, while the URLwithout the query string executes the service request.

In this configuration, all of the Teamcenter services are accessed using HTTP POSTtransactions.



Using client libraries

The Teamcenter Services client libraries are located on the Teamcenter installationCD-ROM, under the soa_client folder. This location includes the actual TeamcenterServices client libraries (Java, C++, and .NET), any libraries that they may bedependent on, and Web-browsable API documentation.

The client libraries for each language or technology are organized as follows:

• Java

– TcSoalibrary-nameTypes.jar

Contain the XSD bindings for the service data structures.

– TcSoalibrary-nameStrong. Jar

Contain the strong model bindings of the service stubs.

– TcSoalibrary-nameLoose. Jar

Contain the loose model bindings of the service stubs.

All Teamcenter services JAR files are Eclipse RCP-ready plug-ins, and maybe referenced in a standard Java JVM classpath, or as a plug-in to an EclipseRCP application.

• C++

– libtcsoalibrary-nametypes.dll


– libtcsoalibrary-namestrong.dll


• .NET

– TcSoalibrary-nameTypes.dll


– TcSoalibrary-nameStrong.dll



Getting started

The Teamcenter Services client libraries have the following dependencies:

Java C++ .NET

CORBA client(two-tier)

jacorb.jaravalon-framework-4.1.5.jarlogkit.jartcgatewaystubs.jar

ACE.dllTAO.dll

Not available

HTTP client(four-tier)

commons-httpclient-2_0_2.jar libcurl.dll TcSoaClient.dll

XML Xerces version 2.6.2:

resolver.jarxercesImpl.jarxml-apis.jarxmlParserAPIs.jar

JAXB version 1.0.5 (JWSDP 1.6):

jaxb-api.jarjaxb-impl.jarjaxb-libs.jarjaxb-xjc.jarjax-qname.jarnamespace.jarrelaxngDatatype.jarxsdlib.jar

Xerces version2.6.2:

icudt32.dllicuin32.dllicuuc32.dllxalan19.dllxerces260.dll

System.Xml.NET FrameworkVersion 2.0

Logging commons-logging.jarlog4j-1.2.8.jar

Not applicable Not applicable



On Microsoft Windows the following compiler and linking options must be set whenusing the Teamcenter Services C++ libraries:

• C++ Compiler Options

Additional IncludeDirectory

The include folder in the soa_client distribution./I “drive\soa_clients\cpp\include”

PreprocessorDefinitions:

/D “IPLIB”

Enable Run-TimeType Info:

/GR

Force Includes: /FI “msvcpragmas.h”

• Link Options

Additional LibraryDirectory

The libs folder in the soa_ client directory distribution./LIBPATH:"drive\soa_client\cpp\libs\wnti32"

AdditionalDependencies

libtcsoacommon.liblibtcsoaclient.liblibtcsoacore.lib

(Any other service libraries your application dependson)


Chapter

2 Introducing the TeamcenterServices framework

What is SOA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Why Teamcenter Services is important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

What you can do with Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Teamcenter Services advantage for your organization . . . . . . . . . . . . . . . . . . 2-2

Teamcenter Services framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Available message transports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Common message structures (input and output) . . . . . . . . . . . . . . . . . . . 2-3Request and response interaction patterns . . . . . . . . . . . . . . . . . . . . . . . 2-4Client data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Errors and exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Object property policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5


Chapter

2 Introducing the TeamcenterServices framework

What is SOA?Service-oriented architecture, or SOA, refers to a style or pattern used in thedevelopment of enterprise-class business applications. Traditional businessapplication development has followed a purpose-built paradigm that is now perceivedas being inflexible and incapable of evolving at the same rapid pace that businessmarkets and processes are now changing. Almost by definition, then, an SOA needsto provide flexibility and the opportunity for business applications to keep pace withchanges in the global business climate.

Teamcenter Services use of SOA utilizes contract-based, coarse-grained interfaces toexpose Teamcenter functionality in a standard way that can be used by Teamcenterclient applications, other UGS applications, and customers’ in-house applications.

The most important characteristics of SOA that allow it to meet these fundamentalobjectives are:

• Contract-based interfaces

SOA promotes the use of abstract interfaces independent of underlying businesslogic implementations. These interfaces represent a contract between clientsand the business applications. As long as the client makes a proper request for aservice, the server honors it and returns a response in the format specified inthe contract. The SOA contract helps to uncouple client and server developmentactivities and allows them to evolve independently so long as the contractremains intact.

• Coarse-grained interfaces

SOA interfaces also tend to be coarse-grained, in the sense that they ideallyrepresent a complete business transaction. The client makes a request for sometype of work to be done; the server executes the full operation without anyintervening conversation with the client, and then sends back a fully-completeresponse to the client. This results in fewer remote calls to API and brings abouta nonchatty interface.


Chapter 2 Introducing the Teamcenter Services framework

• Single entry point to business logic

Once a service is exposed through SOA, it is immediately available to allclients. Because the service is contract-based, the server logic does not need toknow anything about the client requesting the service, which allows new clienttechnologies to be adopted without changing the service or invalidating otherclients using the service.

Why Teamcenter Services is importantTeamcenter Services provides the underpinnings for high performance, scalable,WAN-friendly applications to a degree never before available. Its contract-basedinterfaces ensure stability and longevity for applications built using Teamcenterservices.

What you can do with Teamcenter ServicesServices can be used to create loosely-coupled integrations with Teamcenter,regardless of the programming language standards and operating environmentsprevalent in your organization. You can use services to integrate Teamcenter withthe programming language of your choice. Teamcenter Services includes clientlibraries for Java, .NET and C++, as well as WS-I compliant WSDL so it can beintegrated with virtually any other, previously incompatible, legacy technology.Services can also be used both for interactive, end-user integrations as well as anoninteractive, system-to-system integrations.

Teamcenter Services advantage for your organizationTeamcenter Services provides service interfaces that are both language andtechnology independent. This means that all of your applications can use the sameinterfaces to backend systems, resulting in lower system and maintenance costs foryour organization. The coarse-grained nature of the Teamcenter services interfacesmeans more work gets done in a single request-response cycle, making applicationperformance over high-latency networks possible. Services also provides a client sidedata model (CDM) with added support for SSO and FMS, which takes care of allthe underlying requirements to talk to the server. Your application developers canconcentrate on real functionality that helps your business without getting caughtup in low-level infrastructure development. The inclusion of industry standardWSDL Web service interfaces, which are compliant to the WS-I Basic Profile, enableseasier integration with supplier and partner systems without having to worry aboutproprietary bridges and complex data transforms being built into every application.


Introducing the Teamcenter Services framework

Teamcenter Services frameworkThe Teamcenter Services framework consists of:

• Autogenerated service skeletons on the Teamcenter server.

• Autogenerated service stubs in each of the supported client technologies.

• Standard HTTP communication pipelines and Web-standard middleware.

• A CORBA-based communication pipeline for used in certain Teamcenterconfigurations.

• An autogenerated client data model that exposes the Teamcenter server datamodel to service-based client applications.

The actual Teamcenter service implementations are an integral part of theTeamcenter Server business logic.

Available message transports

Client applications using Teamcenter services can be configured to take advantageof different communication protocols and message transports to connect to theTeamcenter server. In two-tier Teamcenter configurations, where an instance of theTeamcenter server process actually executes on the same end-user computer as theclient application, a tight, CORBA-based integration with the Java and C++ clientlibraries can be used.

In four-tier Teamcenter configurations, where the client and server processesexecute on different computers separated by a network, there is a wider variety ofcommunication styles available. All of the supported client languages can be used(C++, Java, .NET, or WSDL) across standard HTTP communication networks.

Common message structures (input and output)

Teamcenter services are implemented using a small set of patterns or characteristicsto help ensure consistency in how the operation signatures look to developers, aswell as to ensure adherence to internal best practices for Teamcenter. In general,this means that service signatures are set-based and broadly useful over a range ofapplications.

The set-based nature of the services can be seen in operation signatures that take asinput an array or vector of structures. This allows the client application developerto request a similar operation on multiple data model items with a single call tothe server.

Being broadly-applicable is the second noticeable pattern in the way operationsare implemented. For example, even though the attributes necessary in creatingdifferent types of business items can vary widely, the mechanics of doing so is verysimilar form an end-user standpoint. A single Teamcenter service can usually beapplied to multiple business object types. As a result, the overall set of operationsthat a client developer needs to learn is greatly reduced. This pattern also providesa clean mechanism for extending the type of business objects that can be actedupon without having to introduce new operations with slightly different signaturesfor every one.


Chapter 2 Introducing the Teamcenter Services framework

While those two patterns, set-orientation and broad applicability are the defaultapproach to creating service operations, there are places where explicit operationson some business items are provider for the developer’s convenience, or the needs ofspecific, common usages of the service. This approach provides a balance betweencompletely generalized operations and the need for developer convenience in workingthrough certain use cases.

Request and response interaction patterns

A typical request/response cycle used with Teamcenter services requires thefollowing steps:

1. Populate a set of structures representing the business items that you want torequest an operation on.

2. Gather the populated structures into a vector or array as appropriate for theclient technology you are using (C++, Java, .NET, and so on).

3. Instantiate a service from the service stub.

4. Call the operation you are interested in having the Teamcenter server execute.

5. Wait for the Teamcenter server to respond to your request.

6. React to the server response as appropriate for your application. Typicallythis means listening for updates from the client data model ModelManagercomponent and updating the application’s user interface to reflect the resultsof the operation.

Client data model

The language-specific services client libraries contain a client data model (CDM)component that acts as a local data store for Teamcenter data returned by servicemethod calls.

If the client application is using the loosely typed client libraries, the client datamodel is populated with instances of ModelObject objects, a generically-typedlist of a name/value pairs representing the object’s properties. If the client isusing the strongly-typed client libraries, the client data model is populated withtyped objects that correspond one-to-one with their server-side object type. If thespecific server-side type does not exist on the client, the nearest available parenttype is constructed. All properties associated with the type are still available tothe client application.

Client applications can access data in the CDM:

• Through ModelManager listeners.

• Directly from the ServiceData object.

• Through the ModelManager itself.

Each of these methods of accessing CDM data is discussed in detail in Client datamodel components.


Introducing the Teamcenter Services framework

Errors and exceptions

Set-based operations take as input a list of business objects and associatedparameters that control how the Teamcenter server should process each object. Theresult of a set-based operation can be one of three basic conditions:

• Success

• Failure of the requested actions on one or more of the input objects

• Failure

A successful operation typically results in the return of a set of object references inthe ServiceData object, and the object properties themselves in operation-specificstructures.

When an operation fails on one or more of the input objects, but succeeds on others,the failures are referred to as partial error. In this case, the ServiceData objectcontains appropriate ErrorStack entries for each failed item or operation.

When an operation fails, a service exception is generated and returned to thecalling client and must be handled by the application logic which called the serviceoperation.

Object property policies

The object property policy defines which properties are included for a given objecttype when returning objects to the client. The policy is used by the TeamcenterServices framework to automatically and uniformly inflate the properties of objectscontained in the ServiceData object of the services’ returned data structure. ATeamcenter server installation is deployed with a default policy plus any numberof specific policies defined by the different client applications. Each installedapplication using Teamcenter services typically has one or more policies installedon the server.

For more information, see Creating object property policies.


Chapter

3 Using Teamcenter Servicesframework components

Establishing a Teamcenter session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1CredentialManager interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Connection object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Logging on to Teamcenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2ExceptionHandler interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Code example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Calling services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Client data model components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

Handling errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7Partial errors for Teamcenter model data . . . . . . . . . . . . . . . . . . . . . . . . 3-7

Partial errors accessed directly from the ServiceData object . . . . . . . . 3-7Partial errors accessed from a model manager listener . . . . . . . . . . . . 3-7Partial errors for non-Teamcenter model data . . . . . . . . . . . . . . . . . . 3-8

Full service errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

Creating object property policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9Setting the current policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9Defining a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10Policy impact on service performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11


Chapter

3 Using Teamcenter Servicesframework components

Establishing a Teamcenter sessionThere are several steps to establishing a Teamcenter session for your clientapplication:

1. Instantiate a CredentialManager object.

2. Instantiate a Connection object.

3. Call the SessionService.login() operation.

4. Handle exceptions.

CredentialManager interface

The first step in establishing a Teamcenter session is to instantiate aCredentialManager object. The Teamcenter Services framework includes aCredentialManager interface that the client application developer must createan implementation for. It is the responsibility of the client application developer todecide how best to implement the CredentialManager interface in the context oftheir application. The CredentialManager implementation may cache credentials(typically user name and password), or a Teamcenter SSO token) gathered from theuser to allow for silent re-authentication in the case of dropped communications orsession time-outs. Depending on security constraints within your organization theCredentialManager implementation can prompt the user for credentials if there isan issue with the validity of their session.

In maintaining a session between the client application and Teamcenter, the sessionfor your client application may terminate at any time, most commonly becauseof inactivity for more than the maximum period set by the site administrator,or a communications network failure. When this occurs, the client applicationneeds to re-authenticate. Instead of having the client application catch and reactto an InvalidUser exception for every service request, the Teamcenter Servicesframework does this automatically. When the Teamcenter server does return anInvalidUser exception, the client framework uses the CredentialManagerinterface in the Connection object to get the user’s credentials and send theSessionService.login() service request to re-establish a session. Once validated,the service request that originally caused the InvalidUser exception is resubmittedautomatically by the Teamcenter Services framework.


Chapter 3 Using Teamcenter Services framework components

Connection object

The Connection object manages a connection for a single user to a single server.In the most basic and common use case of a client application having a singleuser connecting to a single server, the client application needs to instantiate andmaintain a single instance of the Connection object. It is this Connection objectthat is used to instantiate the appropriate service stubs as service operations areinvoked by the client application.

Even though the Connection object is instantiated, no communication is madeon the configured Connection until a Teamcenter Services operation is actuallyinvoked.

Logging on to Teamcenter

Before any service operation can be invoked, the user must be authenticated. Thisis done through the SessionService.login operation.

Whenever possible, use the SessionService.logout operation to explicitly log auser off of Teamcenter when they exit your application, or when the user does notneed to use the Teamcenter session any longer. This is preferable to allowing thesession to time-out due to inactivity. Waiting for the server to time out the sessioncan cause server resources to be held unnecessarily.

ExceptionHandler interface

Similar to the InvalidUser exception handled by the CredentialManagerinterface, any service request can also throw an InternalServer exception.An InternalServer exception is most commonly caused by a configuration,communication, or programming error. To alleviate the need for the client applicationto catch this exception with every service request, your client application canimplement the ExceptionHandler interface and add it to the Connection object.

Your client application’s implementation of the ExceptionHandler interface candetermine how these exceptions are handled. The handler can display the errormessage, prompt the user to fix the problem and send the request again, throw aRunTimeException exception, or exit the application.


Using Teamcenter Services framework components

Code example

The following code example puts together the four steps for establishing a sessionwith the Teamcenter server:

CredentialManager credentialMgr = new YourAppCredentialManager();ExceptionHandler expHandler = new YourAppExceptionHandler();

Connection connection = new Connection("http://abc.com:7001/tc", new HttpState(),credentialMgr, SoaConstants.REST, SoaConstants.HTTP,true);

connection.setExceptionHandler( expHandler );

SessionService sessionService = SessionService.getService (connection);SavedQueryService queryService = SavedQueryService.getService(connection);String name = “doej”;String pass = “secret”;boolean valid = false;while( !valid ){

try{

LoginResponse out = sessionService.login(name, pass, “”, “”,””);}catch (InvalidCredentialsExceptionType e){

// Display error and prompt for new credentials...

}}GetSavedQueriesResponse resp = service.getSavedQueries();

Calling servicesInvoking a Teamcenter service from the available client bindings is generallythe same and only differs in language syntax. Services are accessed through anabstract class or interface for what is called a base service. The actual servicerequest goes through a stub specific to the transport protocol (HTTP, IIOP, andso on) and binding style (SOAP, REST, and so on) that the client application isconfigured to use. The client application is responsible for obtaining the correct stubimplementation through the static getService() method on the base service classusing information from the Connection object. As long as the run-time stub isinstantiated by the Teamcenter services framework the application code can remainagnostic to the actual transport protocols and binding styles configured. Followingare examples of instantiating a base service and invoking an operation in threedifferent language/model bindings, with bold text indicating the differences betweenthe language/model bindings.

• Java strongly typed data model:import com.teamcenter.services.strong.core.DataManagementService;

// Instantiate the service stubDataManagementService service = DataManagementService.getService( connection );

// Invoke the serviceCreateFoldersResponse out = service.createFolders( folders, container, "child" );

• Java loosely typed data model:import com.teamcenter.services.loose.core.DataManagementService;

// Instantiate the service stubDataManagementService service = DataManagementService.getService( connection );

// Invoke the serviceCreateFoldersResponse out = service.createFolders( folders, container, "child" );



• C++ strongly typed data model:include <teamcenter/services/core/DataManagementService.hxx>

// Instantiate the service stubDataManagementService* service = DataManagementService.getService( connection );

// Invoke the serviceCreateFoldersResponse out = service->createFolders( folders, container, "child");

• .NET strongly typed data model:using Teamcenter.Services.Strong.Core;

// Instantiate the service stubDataManagementService service = DataManagementService.GetService( connection );

// Invoke the serviceCreateFoldersResponse out = service.CreateFolders( folders, container, "child" );



Client data model componentsThe key components of the client data model are the ServiceData object, theModelManager object, and the ErrorStack object.

The ServiceData object is a collection of Teamcenter data model objects sortedinto lists: created, deleted, updated, or plain. These lists are populated as part ofexecuting an operation on the Teamcenter server and passed back as part of theresponse to each service request. If the client is using the loosely typed languagebinding, the client data model (CDM) is populated by ModelManager with instancesof the ModelObject class, collectively called model objects. The model objectsrepresent the properties of an object as collections of generic name/value pairs.

If the client is using any of the strongly typed language bindings, the CDM ispopulated by the ModelManager object with object instances of the same type thatthe object has on the Teamcenter server. If the specific type does not exist on theclient, the nearest available parent type is constructed.

Client applications can directly access the four ServiceData list structure usingmethods built into the ServiceData object. Methods are available to return thenumber of object references in each list as well as to return the object at a specificindex within the list, as shown in the following example:

ServiceData manyItems = fooService.operationBar(uids, true);

// Loop through one or more of the arrays contained within ServiceData.// Service documentation should make it clear which arrays may have datafor(int i=0; i<manyItems.sizeOfCreatedObjects();i++){

ModelObject singleItem = manyItems.getCreatedObject(i);// Since we are working with the Strongly Typed Data Model// we can cast the singleItem object to something more specificif(singleItem instanceof GeneralDesignElement){

GeneralDesignElement gde = (GeneralDesignElement)singleItem;System.out.println("Is Frozen: "+gde.getIs_frozen()); //POMObjectSystem.out.println("Cardinality: "+gde.getCardinality());//GDE object

}}

Each list within the ServiceData object can be accessed by substituting thesizeOfCreatedObjects() and getCreatedObject(i) methods in the sample withthe appropriate one of sizeOfDeletedObjects(), sizeOfChangedObjects(), orsizeOfPlainObjects() and getDeletedObjects(), getChangedObjects(), orgetPlainObjects(). While this approach to retrieving returned data is usefulin some cases, a more convenient listener-based approach is provided by theModelManager object.



The ModelManager object is member of the Connection object that is in use.ModelManager serves as an intermediary between local object storage and thewire-level representations of Teamcenter objects. Its most significant featurefrom an application developer’s perspective is its exposure of listeners that canbe used to notify the client application when data is returned from a service call.Client applications can instantiate any number of change, delete, or partial errorlisteners, each of which are invoked by ModelManager as data corresponding toeach listener type is returned from the server. The following example shows theuse of a ChangeListener component:

modelManager.addChangeListener( new ChangeListener(){

// The client application can implement instances of the// ChangeListener to take appropriate action when object have changedpublic void modelObjectChange( ModelObject[] changedObjs ){

for (int i = 0; i < changedObjs.length; i++){

// The ModelManager will provide a list of ModelObjectif(changedObjs[i]instanceof POMObject){

POMObject changedItem = (POMObject)changedObjs[i];System.out.println("Is Frozen: "+changedItem.getIs_frozen());

}}

}});

DeleteListener and PartialErrorListener instances can be created and used inthe same manner for the ChangeListener. Client application developers should usethe ModelManager listeners unless there is a specific need to access the data eitherdirectly from the ServiceData object, or directly from the ModelManager object.

The ModelManager object also exposes a method to directly retrieve objectsinstances by their UID. In general, a client application has little use for accessingmodel objects in this manner; the application gets the object directly from theServiceData class or from the model manager listeners.

ModelObject someItem = modelManager.getObject("xyz123");

if(someItem instanceof GeneralDesignElement){

GeneralDesignElement gde = (GeneralDesignElement)someItem;System.out.println("Is Frozen: "+gde.getIs_frozen());System.out.println("Cardinality: "+gde.getCardinality());

}

All three of these options are available regardless of whether the client application isoperating with the strongly typed or loosely typed bindings; the only difference is inthe type of the returned object.



Handling errorsTeamcenter Services can handle partial or full errors.

Partial errors for Teamcenter model data

The majority of Teamcenter service operations are set-based. The operation maysucceed on some of the objects in the set while failing on others. To notify the clientapplication of the failure on the subset of input objects, a PartialErrors structureis included in the ServiceData. The client application has several options foraccessing partial errors returned from a service operation.

Partial errors accessed directly from the ServiceData object

The ServiceData object contains a list of partial errors. This list may have 0or more error stacks on it. Each error stack has a list of one or more errors thatcontributed to this particular failed action. The service implementation may alsoset a client ID or associated model object; these are provided to help the clientapplication identify which object this partial error is for.

ServiceData manyItems = fooService.operationBar();// Loop through one or more of the arrays contained within ServiceData.// Service documentation should make it clear which arrays may have datafor(int i=0; i<manyItems.sizeOfErrors();i++){

ErrorStack errorStack = manyItems.getPartialError(i);String clientId = errorStack.getClientId();ModelObject assocObj = errorStack.getAssociatedObject();String[] messages = errorStack.getMessages();for(int j=0; j< messages.length;j++){

System.out.println( messages[j] );}

}

Partial errors accessed from a model manager listener

The model manager provides the PartialErrorListener to notify the clientapplication when partial errors have been returned from any Teamcenter serviceoperation. The client application may create any number of implementation of thislistener. The model manager invokes each instance of the listeners as appropriatedata is returned from a service operation.

modelManager.addPartailErrorListener( new PartialErrorListener(){

public void handlePartialError(ErrorStack[] partialErrors ){

// Loop through the list of Partial Errors.for(int i=0; i<partialErrors.length;i++){

ErrorStack errorStack = partialErrors[i];

// The Partial Error may have a client ID or a Model// Object associated with itSystem.out.println("Error for client Id "+

errorStack.getClientId());Modelbject assocObj = errorStack.getAssociatedObject();

// Each Partial Error may have 1 or more sub-errorsString[] messages = errorStack.getMessages();for(int j=0; j< messages.length;j++){


}}

});



Partial errors for non-Teamcenter model data

For set-based service operations that do not return a ServiceData object, partialerrors may be returned as part of any returned data structure.

BarResponse out = fooService.operationBar();for(int i=0; i<out.partialErrors.size();i++){

ErrorStack errorStack = out.partialErrors.getErrorStack(i);String clientId = errorStack.getClientId();ModelObject assocObj = errorStack.getAssociatedObject();String[] messages = errorStack.getMessages();for(int j=0; j< messages.length;j++){


}

Full service errors

A ServiceException exception is thrown only when the implementation of serviceoperation expects the client application to do special processing when the operationfails as a whole (not only partial errors). For service operations that define thatServiceException may be thrown, the client application must surround theseservice requests with a try/catch block:

try{

// Execute the service requestString out = fooService.operationBar ( );System.out.println("Service out:"+out);

}// The service may have thrown an errorcatch (ServiceException e){

String[] messages = e.getMessages();for (int i = 0; i < messages.length; i++){

// The Error may have 1 or more sub-errorsSystem.out.println( messages[i] );

}}



Creating object property policiesThe object property policy defines which properties are included for a given objecttype when returning objects to the client. The policy is used by the TeamcenterServices framework to automatically and uniformly inflate the properties of objectscontained in the service data of an operation’s returned data structure. A Teamcenterserver deployment includes a default policy provided by the framework alongwith any number of specific policies defined by the Teamcenter client applicationsthemselves. Each installed application using Teamcenter services typically has oneor more policies defined on the Teamcenter server.

Setting the current policy

The client application can specify a policy for the Teamcenter Services frameworkto enforce by calling the Session.setObjectPropertyPolicy() operation. If theclient application does not specify a policy, the Teamcenter Services framework usesthe default application policy. Client applications are responsible for defining andmaintaining at least one object property policy.

Policies are configured in XML files. They are stored in a Teamcenter volume in a$TC_DATA/soa/policies/policy-name.xml file.

Once a policy is set using Session.setObjectPropertyPolicy(), itis enforced for the duration of the current session, or until the nextSession.setObjectPropertyPolicy() request is received. The reserved policycalled Empty enforces a policy that only returns minimum data for each object,typically UID and Teamcenter TypeName.

The framework provides convenience methods on the Connection class to get thename of the current policy as well as the previous policy. Providing both makesit easier for application developers to set a policy for a single operation and thenquickly restore the previous policy without having to store the previous policy nameahead of time.



Defining a policy

The object property policy is a list of Teamcenter classes and/or types and propertiesassociated with those classes and types. The properties defined in a parent classare inherited by child classes. The policy syntax supports referencing Teamcenterpreferences to specify additional properties. Each policy file has a customizationpoint to allow site administrators to add additional types and properties withouthaving to edit the original delivered policy. The following code is an example ofa simple policy configuration:

<ObjectPropertyPolicy xmlns="http://teamcenter.com/Schemas/Soa/ObjectPropertyPolicy" ><Include file="site/SiteDefault.xml ">

<ObjectType name="WorkspaceObject"><Property name="object_string" />

<Property name="object_type" /></ObjectType>

<ObjectType name="Folder"><--Inherits properties from WorkspaceObject--></ObjectType><ObjectType name="User"><Property name="user_name" /><Property name="default_group" /><Property name="home_folder" withProperties="true" /><Property name="userinbox" /></ObjectType>

<ObjectType name="Item"><Property name="has_variant_module" /><Property name="is_configuration_item" /></ObjectType>

<ObjectType name="ItemRevision"><Property name="view" /><Property name="items_tag" /></ObjectType>

<ObjectType name="BOMLine"><Property name="bl_has_children" /><Property name="bl_is_variant" /><Preference name="PortalPSEColumnsShownPref" /></ObjectType>

</ObjectPropertyPolicy>

In the example, Item and ItemRevision objects not only have the property valuesreturned for the properties defined under those types but also the properties definedunder the WorkspaceObject object, because the WorkspaceObject object is theparent for both Item and ItemRevision. BOMLine objects have property valuesfor the two properties explicitly named, and all of the property names defined in thePortalPSEColumnsShownPref preference variable.

Optionally the Property element can include the withProperties attribute. Bydefault, the object property policy is applied only to the objects explicitly returnedby the service implementations. If the service returns a User object and thehome_folder property is part of the policy, the referenced home_folder objectis added to the return data, but without any associated properties. By addingwithProperties="true" to the home_folder property, properties for home folderare also returned.

Additional types and properties specified in the MySitePolicy.xml file are includedin this policy.



Policy impact on service performance

As a Teamcenter client application developer, you should not need to be concernedwith what is happening within service requests. The one major exception to thatarises from the fact that an ill-conceived or poorly implemented object propertypolicy can seriously impact system overhead and application performance.

In a more traditional programming model, the functionality of the object propertypolicy would be included in the business logic of a service, where the business logicwould not only assemble a list of model objects to return, but also the property valuesassociated with each of those objects. In the Teamcenter Services environment,the business logic only determines which objects are returned; by default, thoseobjects are returned without any associated properties. It is the Teamcenter Servicesframework’s enforcement of the object property policy that retrieves the objectproperties and adds them to the operation’s return structure. By allowing theclient application developer to choose what types and properties make up an objectproperty policy and providing the ability to set which policy is being enforced givesthe client application large control over the amount of data returned by an operation.



Figure 3-1 compares two service requests each returning 250 objects. The firstservice request uses an object property policy that only defines one property for thegiven object type, for a total of 250 properties being returned, while the secondservice requests uses an object property policy that defines 10 properties for thegiven object type, for a total of 2,500 properties being returned. The red section of thebar shows the relative time spent inflating properties. This is where the TeamcenterServices framework uses the current policy to retrieve the desired properties foreach object in the ServiceData object.

0%

50%

100%

40%

20%

90%

80%

70%

60%

30%

10%

Web Tier

Business Logic

Server Inflate Properties

Client Parse XML

Server Serialize XML

Relative Times in Service Call Stack(250 Objects)

1 Property/Object 10 Properties/Object

Figure 3-1. Object property policy impact on performance



It does not matter how the properties are distributed across the returned objects,whether each object has 10 properties, or that some object types have 3 propertiesand others have 15. All that matters is the total number of properties that theproperty policy manager of the Teamcenter Services framework needs to retrievefrom the database and add to the service response. Figure 3-2 shows a very linearincrease in execution time with the increase in total number of properties returned.

0

500

1000

1500

2000

2500

5000 250 750 1000 15001250 1750 2000 25002250

Inflate Properties Execution Times

Total Number of Properties

Mill

isec

onds

Figure 3-2. Object project policy effect on execution time

Applications should use policies that return the data needed for the use casesthey support and be careful not to retrieve too many properties in case they maybe needed in a subsequent operation.


Chapter

4 Teamcenter Services organization

Teamcenter System Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Teamcenter System Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3Administration library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

UserManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Teamcenter Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4Core library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

DataManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5FileManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6IRM service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6ManagedRelations service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7Reservation service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7Session service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

Teamcenter Application Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9Allocations library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9

Allocations service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10CalendarManagement library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11

CalendarManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11CrfReports library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

CrfReports service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12Query library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

SavedQuery service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

Teamcenter Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14Classification library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14

Classification service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15ProjectManagement library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16

ScheduleManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16RequirementsManagement library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17

RequirementsManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17DocumentManagement library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18

DocumentTemplate service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18

Teamcenter Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19

Teamcenter Application Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20AI library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20

AI service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20CAD library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22

DataManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23StructureManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24


Chapter

4 Teamcenter Services organization

Teamcenter services APIs are organized as a hierarchy of functional areas, libraries,services, and operations. API documentation can be found on the Teamcenterinstallation software distribution image at the following location:

soa_client\java\docs\api

Figure 4-1 illustrates the service organization. At the highest level are the functionalareas, a small number of coarse-grained categories into which the various API codelibraries are organized. A functional area can have any number of libraries withinit. A library corresponds to a compiled code artifact such as a DLL on Windows, oran SO on other platforms, and contains one or more services relating to particularTeamcenter functionality or capabilities. Within each service are a set of one or moreoperations which make up the actual callable methods on the API.

Applications

Classification::ClassificationServiceDocumentManagement::DocumentTemplateServiceProjectManagement::ScheduleManagementServiceRequirementsManagement::RequirementsManagementService

Application Integration

AI::AIServiceCAD::DataManagementServiceCAD::StructureManagementService

Application Support

Allocations::AllocationServiceCalendarManagement::CalendarManagementServiceQuery::SavedQueryServiceReports::CrfReportsService

System Administration

Core::UserManagement

System Definition

Platform

Core::DataManagementServiceCore::FileManagementServiceCore:IRMServiceCore::ManagedRelationServiceCore::ReservationServiceCore::SessionService

Figure 4-1. Teamcenter service functional organization


Chapter 4 Teamcenter Services organization

Teamcenter System DefinitionThe System Definition functional area contains the functionality used by theTeamcenter Business Modeler IDE and other tools to define and customize aparticular Teamcenter installation or system deployment. There is not anyfunctionality in these libraries that is used for day-to-day administration or end-useractivities.

There are currently no public services or operations exposed for Teamcenter SystemDefinition.


Teamcenter Services organization

Teamcenter System AdministrationThe System Administration library functional area contains the libraries related tothe day-to-day administration of a Teamcenter system or deployment. Along withthe Teamcenter Platform services and Teamcenter Application Support services, theoperations exposed can be used in a variety of custom administration scenarios thatmay be important to your organization.

Administration library

The Administration library currently exposes a single service, UserManagement.

The following files are used for the Administration library:

• Java

TcSoaAdministrationTypes.jarTcSoaAdministrationStrong.jarTcSoaAdministrationLoose.jar

• C++

libtcsoaadministrationtypes.dlllibtcsoaadministrationstrong.dll

• C#

TcSoaAdministrationTypes.dllTcSoaAdministrationStrong.dll

UserManagement service

The UserManagement service currently exposes a single service,createDisciplines.

Following are the namespaces for the UserManagement service:

• Javacom.teamcenter.services.strong.core.UserManagemtService

• C++Teamcenter::Services::Core::UserManagementService

• C#Teamcenter.Services.Strong.Core.UserManagementService



Teamcenter PlatformThe Teamcenter Platform functional area contains those libraries, services, andoperations that are considered fundamental to how data is stored, managed, andaccessed in Teamcenter. These libraries as such are independent of any particularTeamcenter application space. They make up the core of functionality that all otherapplication areas are built upon.

Core library

The following files are used for the Core library:

• Java

TcSoaCoreTypes.jarTcSoaCoreStrong.jarTcSoaCoreLoose.jar

• C++

libtcsoacoretypes.dll/libtcsoacorestrong.dll

• C#

TcSoaCoreTypes.dllTcSoaCoreStrong.dll

The Core library currently contains five services:

DataManagementFileManagementIRMManagedRelationsReservationSession



DataManagement service

The DataManagement service exposes operations that are common to virtually allstandard and custom Teamcenter applications, including the creation, and deletionof items to be managed, relating items to each other, organizing them into folders,attaching bulk data to items, and specifying the ownership and identification ofmanaged items. It also includes operations for specifying item properties andidentifying where items are referenced or used by other items throughout the system.

Following are the namespaces for the DataManagement service:

• Javacom.teamcenter.services.strong.core.DataManagemtService

• C++Teamcenter::Services::Core::DataManagementService

• C#Teamcenter.Services.Strong.Core.DataManagementService

This service contains the following operations:

changeOwnershipcreateDatasetscreateFolderscreateItemscreateOrUpdateFormscreateRelationsdeleteObjectsdeleteRelationsgenerateItemIdsAndInitialRevisionIdsgenerateRevisionIdsgenerateUIDgetDatasetCreationRelatedInfogetItemCreationRelatedInfogetItemFromIdgetPropertiesmoveToNewFolderrefreshObjectsrevisesetDisplayPropertiessetPropertieswhereReferencedwhereUsed



FileManagement service

The Teamcenter Platform FileManagement service exposes operations used inuploading and downloading persistent files associated with items managed in theTeamcenter system, or transient files which represent either the input to, or theoutput from, various Teamcenter import/export functions.

Following are the namespaces for the FileManagement service:

Javacom.teamcenter.services.strong.core.FileManagemtService

C++Teamcenter::Services::Core::FileManagementService

C#Teamcenter.Services.Strong.Core.FileManagementService


commitDatasetFiles)getDatasetWriteTicketsgetFileReadTicketsgetTransientFileTicketsForUpload

IRM service

The Identity and Rights Management (IRM) service exposes operations used to setor retrieve information about a user’s privileges on the system, or their privilegesregarding accessing and manipulating items or types of items within Teamcenter.

Following are the namespaces for the IRM service:

• Javacom.teamcenter.services.strong.core.IRMService

• C++Teamcenter::Services::Core::IRMService

• C#Teamcenter.Services.Strong.Core.IRMService


checkAccessorsPrivilegesgetEffectiveACLInfogetExtraProtectionInforemoveAccessorsetPrivileges



ManagedRelations service

Managing the formal relationships between business items is a primary reasonfor implementing Teamcenter, so it is natural that Teamcenter has operationsspecifically geared towards creating and managing these formal relations. TheManagedRelations service exposes operations that can be used to createrelationships between items, modify existing relationships between items in thesystem, and return information that can be used to generate traceability reportswhich show those relationships.

Following are the namespaces for the ManagedRelations service:

• Javacom.teamcenter.services.strong.core.ManagedRelationsService

• C++Teamcenter::Services::Core::ManagedRelationsService

• C#Teamcenter.Services.Strong.Core.ManagedRelationsService


createRelationgetTraceReportmodifyRelation

Reservation service

The Reservation service exposes operations that are used to control the concurrentrevisioning of items in the system. Very much like a source code control system, theTeamcenter Reservation service allows items to be checked out to be worked on, andlater checked back into the system as a new revision of the item. An operation forretrieving an item’s reservation history is also available in this service.

Following are the namespaces for the Reservation service:

• Javacom.teamcenter.services.strong.core.ReservationService

• C++Teamcenter::Services::Core::ReservationService

• C#Teamcenter.Services.Strong.Core.ReservationService


cancelCheckoutcheckincheckoutgetReservationHistory



Session service

The Session service exposes operations that can be used to establish a client or usersession with the Teamcenter server. A session can be established through a standardusername/password style logon operation, or through the use of Teamcenter SecurityServices (TSS or TcSSO) credentials. Once a session is established, informationabout the logged-in user, their membership various administrative groups and roles,and their preferred system settings can be set or retrieved. At the conclusion of asession the supplied logout operation should be performed to inform the Teamcenterserver that this session is no longer needed.

Following are the namespaces for the Session service:

• Javacom.teamcenter.services.strong.core.SessionService

• C++Teamcenter::Services::Core::SessionService

• C#Teamcenter.Services.Strong.Core.SessionService


getAvailableServicesgetGroupMembershipgetPreferencesgetSessionGroupMembergetTCSessionInfologinloginSSOlogoutsetObjectPropertyPolicysetPreferencessetSessionGroupMember



Teamcenter Application SupportThe Application Support functional area contains the libraries and services thatserve the common needs of day-to-day, end user applications. The services andoperations that are made available here support standard mechanisms for systemqueries and searches, report definition and generation, creation and maintenance ofcalendars used in project management and workflow applications.

Allocations library

The Allocations library currently contains a single service, Allocations, that exposesoperations used to manage complex, one-to-many and many-to-one relationshipsbetween items in the Teamcenter system.

The following files are used for the Allocations library:

• Java

TcSoaAllocationsTypes.jarTcSoaAllocationsStrong.jarTcSoaAllocationsLoose.jar

• C++

libtcsoaallocationstypes.dlllibtcsoaallocationsstrong.dll

• C#

TcSoaAllocationsTypes.dllTcSoaAllocationsStrong.dll



Allocations service

The Allocations service exposes operations that are used to establish and maintaincomplex, one-to-many, many-to-one, and many-to-many relationships between itemsin the Teamcenter system. Common uses for allocations include requirementsmanagement, systems engineering, and other application domains that requirethese types of complex relationships. These operations can also be used in productconfiguration applications to ensure that design constraints and mandatoryselections on product options are satisfied.

Following are the namespaces for the Allocations service:

• Javacom.teamcenter.services.strong.allocations.AllocationService

• C++Teamcenter::Services::Allocations::AllocationService

• C#Teamcenter.Services.Strong.Allocations.AllocationService


addAllocationLineschangeAllocatedBOMWindowschangeAllocationContextchangeICContextcloseAllocationWindowcreateAllocationContextdeleteAllocationLinesfindAllocatedBOMViewsfindAllocationContextsgetBOMViewsmodifyAllocationLinesopenAllocationWindowsaveAllocationWindow



CalendarManagement library

The CalendarManagement library currently contains a single service,CalendarManagement.

The following files are used for the CalendarManagement library:

• Java

TcSoaCalendarManagementTypes.jarTcSoaCalendarManagementStrong.jarTcSoaCalendarManagementLoose.jar

• C++

libtcsoacalendarManagementypes.dlllibtcsoacalendarManagementstrong.dll

• C#

TcSoaCalendarManagementTypes.dllTcSoaCalendarManagementStrong.dll

CalendarManagement service

The CalendarManagement service exposes operations used in the creation andmaintenance of calendars used in scheduling, project management, and workflowapplications. The exposed operations provide standard create, modify, update, anddelete capabilities, as well as the general ability to retrieve calendars for use inapplications.

Following are the namespaces for the CalendarManagement service:

• Javacom.teamcenter.services.strong.CalendarManagement.CalendarManagementService

• C++Teamcenter::Services::CalendarManagement::CalendarManagementService

• C#Teamcenter.Services.Strong.CalendarManagement.CalendarManagementService


createTCCalendarsdeleteTCCalendarsgetTCCalendarsmodifyTCCalendarsupdateTCCalendars



CrfReports library

The Common Reporting Framework library, CrfReports, contains a single service,also called CrfReports.

The following files are used for the CreReports library:

• Java

TcSoaReportsTypes.jarTcSoaReportsStrong.jarTcSoaReportsLoose.jar

• C++

libtcsoareportstypes.dlllibtcsoareportsstrong.dll

• C#

TcSoaReportsTypes.dllTcSoaReportsStrong.dll

CrfReports service

The CrfReports service exposes operations that allow for the definition andgeneration of Teamcenter reports in a standard fashion for all Teamcenterapplications. Operations are also available to autogenerate report identifiers and toretrieve existing report definitions that meet the user’s input criteria.

Following are the namespaces for the CrfReports service:

• Javacom.teamcenter.services.strong.Reports.CrfReportsService

• C++Teamcenter::Services::Reports::CrfReportsService

• C#

Teamcenter.Services.Strong.Reports.CrfReportsService


createReportDefinitiongenerateReportgenerateReportDefintionIdsgetReportDefinitions



Query library

The Teamcenter Query library currently contains a single service called theSavedQuery service.

The following files are used for the Query library:

• Java

TcSoaQueryTypes.jarTcSoaQueryStrong.jarTcSoaQueryLoose.jar

• C++

libtcsoaquerytypes.dlllibtcsoaquerystrong.dll

• C#

TcSoaQueryTypes.dllTcSoaQueryStrong.dll

SavedQuery service

The SavedQuery service exposes operations that allow the creation, execution, andmaintenance of predefined queries stored within the Teamcenter system. Teamcenterships with a wide range of predefined queries covering many common productdata management use cases. Customer administrators and end users can createadditional queries that can be saved into the system and used by other end users.

Following are the namespaces for the SavedQuery service:

• Javacom.teamcenter.services.strong.Query.SavedQueryService

• C++Teamcenter::Services::Query::SavedQueryService

• C#

Teamcenter.Services.Strong.Query.SavedQueryService


describeSavedQueriesexecuteSavedQuerygetSavedQueries



Teamcenter ApplicationsThe Applications functional area contains libraries for specific capabilities andindustry solutions.

Classification library

The Classification library currently contains a single service, also calledClassification.

The following files are used for the Classification library:

• Java

TcSoaClassificationTypes.jarTcSoaClassificationStrong.jarTcSoaClassificationLoose.jar

• C++

libtcsoaclassificationtypes.dlllibtcsoaclassificationstrong.dll

• C#

TcSoaClassificationTypes.dllTcSoaClassificationStrong.dll



Classification service

The Classification service exposes operations that correspond to the specificcapabilities found in the Teamcenter InClass application. InClass is a Teamcenterapplication that is used to classify Teamcenter items, typically the parts andassemblies making up manufactured products, into a hierarchy of categories,somewhat like a catalog. It also provides operations which allow the classified itemsto be searched by attribute, attribute value, classifications, and other criteria.

Following are the namespaces for the Classification service:

• Javacom.teamcenter.services.strong.Classification.ClassificationService

• C++Teamcenter::Services::Classification::ClassificationService

• C#Teamcenter.Services.Strong.Classification.ClassificationService


createClassificationObjectsdeleteClassificationObjectsfindClassificationObjectsfindClassifiedObjectsgetAttributesForClassesgetChildrengetClassDescriptionsgetClassificationObjectsgetFileIdsgetKeyLOVsgetParentsgetPartFamilyTemplatessearchsearchByInstanceIdsearchForClassesupdateClassificationObjects



ProjectManagement library

The ProjectManagement library currently contains a single service:ScheduleManagement.

The following files are used for the ProjectManagement library:

• Java

TcSoaProjectManagementTypes.jarTcSoaProjectManagementStrong.jarTcSoaProjectManagementLoose.jar

• C++

libtcsoaprojectmanagementtypes.dlllibtcsoaprojectmanagementstrong.dll

• C#

TcSoaProjectManagementTypes.dllTcSoaProjectManagementStrong.dll

ScheduleManagement service

The ScheduleManagement service exposes operations that allow for the creationand maintenance of schedules within Teamcenter. These operations are used bythe Teamcenter project application but are also available for use in customerapplications. Standard operations for the creation and maintenance of projectschedules, baselining projects, and adding personnel and calendars are also exposed.

Following are the namespaces for the ScheduleManagement service:

• Javacom.teamcenter.services.strong.ProjectManagement.ScheduleManagementService

• C++Teamcenter::Services::ProjectManagement::ScheduleManagementService

• C#

Teamcenter.Services.Strong.ProjectManagement.ScheduleManagementService


addMembershipsbaselineTaskscopySchedulescreateNewBaselinescreateSchedulecreateScheduleDeliverableTemplatescreateTaskDeliverableTemplatesdeleteSchedulingObjects



RequirementsManagement library

The Teamcenter RequirementsManagement library currently contains a singleservice, also called RequirementsManagement.

The following files are used for the RequirementsManagement library:

• Java

TcSoaRequirementsManagementTypes.jarTcSoaRequirementsManagementStrong.jarTcSoaRequirementsManagementLoose.jar

• C++

libtcsoarequirementsmanagementtypes.dlllibtcsoarequirementsmanagementstrong.dll

• C#

TcSoaRequirementsManagementTypes.dllTcSoaRequirementsManagementStrong.dll

RequirementsManagement service

The RequirementsManagement service exposes operations used by theTeamcenter Requirements and Teamcenter Systems Engineering applications. Inaddition to allowing the creation and maintenance of individual requirementsas plain text, the RequirementsManagement service allows rich content(formatted text, diagrams, pictures, and so on) to be imported from common desktopapplications. Once imported, this rich content can be exported back out to a desktopapplication, edited in realtime, and imported back into Teamcenter.

Following are the namespaces for the RequirementsManagement service:

• Javacom.teamcenter.services.strong.RequirementsManagement.RequirementsManagementService

• C++Teamcenter::Services::RequirementsManagement::RequirementsManagementService

• C#Teamcenter.Services.Strong.RequirementsManagement.RequirementsManagementService


createOrUpdateexportToApplicationgetRichContentimportFromApplicationsetRichContent



DocumentManagement library

The Teamcenter DocumentManagement library currently contains a singleservice, the DocumentTemplate service.

The following files are used for the DocumentManagement library:

• Java

TcSoaDocumentManagementTypes.jarTcSoaDocumentManagementStrong.jarTcSoaDocumentManagementLoose.jar

• C++

libtcsoadocumentmanagementtypes.dlllibtcsoadocumentmanagementstrong.dll

• C#

TcSoaDocumentManagementTypes.dllTcSoaDocumentManagementStrong.dll

DocumentTemplate service

The DocumentTemplate service exposes a single operation, getTemplates, whichallows for the retrieval of information on the desktop applications that variousapplication file types are associated with. Various criteria can be specified in order toretrieve the subset of templates that are appropriate to the file types the applicationis interested in at the moment.

Following are the namespaces for the DocumentTemplate service:

• Javacom.teamcenter.services.strong.DocumentManagement.DocumentTemplateService

• C++Teamcenter::Services::DocumentManagement::DocumentTemplateService

• C#Teamcenter.Services.Strong.DocumentManagement.DocumentTemplateService



Teamcenter Distributed SystemsThe Distributed Systems functional area covers two major areas of Teamcenterfunctionality: Teamcenter Global Services and those portions of Global Services thataddress connectivity and functionality across and between Teamcenter installations.Other portions of Teamcenter Global Services address integration with non-PLMsystems and are more appropriately included in the Application Integrationfunctional area.

Only the MultiSite library is defined within the Distributed Systems functionalarea. It has services for Object Directory interaction and IDSM Transfers.

There are currently no libraries or services published in the category TeamcenterDistributed Systems.



Teamcenter Application IntegrationTeamcenter applications are generally deployed as one part of a corporateinformation environment that includes a variety of non-PLM systems andapplications. Applications and information managed by Teamcenter must be easilyaccessible and interoperate smoothly with those other systems and applications.

AI library

The AI library currently contains a single service, also called AI. The applicationintegration capabilities that were exposed through AIWS in earlier versions havebeen incorporated into the new services API set. The AIWS implementations havebeen deprecated and should no longer be used for new development.

The following files are used for the AI library:

• Java

TcSoaAITypes.jarTcSoaAIStrong.jarTcSoaAILoose.jar

• C++

libtcsoaaitypes.dlllibtcsoaaistrong.dll

• C#

TcSoaAITypes.dllTcSoaAIStrong.dll

AI service

The AI service exposes operations that are consistent with application integrationparadigm and conventions established through AIWS.

The new AI operations allow multiple client sessions to be logged on the sameTeamcenter server simultaneously. You should ensure that the client discriminatorargument in the logon operation of the Session service is used to distinguish thedifferent instances of the client running with the same logon user.

A sample services AI client is provided under the soa_client directory on theTeamcenter CD-ROM.

Following are the namespaces for the AI service:

• Javacom.teamcenter.services.strong.AI.AIService

• C++Teamcenter::Services::AI::AIService

• C#Teamcenter.Services.Strong.AI.AIService




commitFilescommitStructureFilecreateProjectscreatePublishRequestdeleteProjectsdeleteRequestsendExchangegenerateFullSyncRequestgenerateStructuregetFileReadTicketsgetFileWriteTicketsgetNextApprovedRequestgetProjectsgetProjectsInfogetPropertiesOfObjectsgetRequestsForProjectgetRequestsInfogetStructureReadTicketgetStructureWriteTicketobjectsExistprocessPublishRequestprocessStructuresetExchangeMessagesetProjectsInfostartExchange



CAD library

The CAD library currently exposes two services: DataManagement andStructureManagement. One of the primary applications of Teamcenter incustomer operations is as a managed environment for engineering information,whether it is generated through computer-aided design (CAD) tools such as NXor other computer-aided engineering (CAE/CAx) applications. As a result, theTeamcenter CAD services provide a robust set of operations that facilitate theintegration of these and similar engineering tools with Teamcenter.

The following files are used for the CAD library:

• Java

TcSoaCadTypes.jarTcSoaCadStrong.jarTcSoaCadLoose.jar

• C++

libtcsoacadtypes.dlllibtcsoacadstrong.dll

• C#

TcSoaCadTypes.dllTcSoaCadStrong.dll



DataManagement service

The CAD DataManagement service exposes operations that are, in many ways,similar to the core DataManagement services described earlier. The differenceis that the CAD operations have been specifically designed with the needs ofdesign engineers and design applications which need to be tightly integrated withTeamcenter.

Following are the namespaces for the DataManagement service:

• Javacom.teamcenter.services.strong.Cad.DataManagementService

• C++Teamcenter::Services::Cad::DataManagementService

• C#Teamcenter.Services.Strong.Cad.DataManagementService


createOrUpdatePartscreateOrUpdateRelationsexpandFoldersForCADexpandGRMRelationsexpandPrimaryObjectsgenerateAlternateIdsgetAllAttrMappingsgetAttrMappingsForDatasetTypegetAvailableTypesresolveAttrMappingsForDataset



StructureManagement service

The CAD StructureManagement service exposes operations that allow variouskinds of engineering structures (parts, assemblies, and so on) to be easilymanipulated within a managed engineering application environment. In thisscenario, the structure of the product being designed can be authored in theengineering tool, but stored and managed in Teamcenter. The operations exposed bythis service help provide for an exceptional user experience in these situations.

Following are the namespaces for the StructureManagement service:

• Javacom.teamcenter.services.strong.Cad.StructureManagementService

• C++Teamcenter::Services::Cad::StructureManagementService

• C#Teamcenter.Services.Strong.Cad.StructureManagementService


closeBOMWindowscreateBOMWindowscreateOrUpdateAbsoluteStructurecreateOrUpdateRelativeStructuredeleteAssemblyArrangementsdeleteRelativeStructureexpandPSAllLevelsexpandPSOneLevelgetRevisionRulesgetVariantRules


Chapter

5 Performing common tasksusing services

Retrieving basic item information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Uploading and downloading persistent files . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Importing and exporting data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4


Chapter

5 Performing common tasksusing services

The basic pattern for invoking Teamcenter services operations is as follows:

1. Populate a set of structures representing the business items that you want torequest an operation on.

2. Gather the populated structures into a vector or array as appropriate for theclient technology you are using (C++, Java, .NET, and so on).

3. Request a service stub from the Connection object your session is runningunder.

4. Call the operation you are interested in having the Teamcenter server execute.

5. Wait for the Teamcenter server to respond to your request.

6. React to the server response as appropriate for your application. Typically thismeans listening for updates from the CDM model manager and updating theapplication’s user interface to reflect the results of the operation.

Most operations take arrays of structures as their input, and return a standardServiceData object along with one or more operation-specific output structures.Refer to the online services references or the WSDL files and schemas for details onthese structures.


Chapter 5 Performing common tasks using services

Retrieving basic item informationBasic information about items returned from an operation is contained within theServiceData object returned from the call. The information in the ServiceDataobject is controlled through the ObjectPropertyPolicy in place at the time of theoperation request. If additional information about the one or more of the returnedobjects is needed, the DataManagement.getProperties() operation can be called.The input to the DataManagement.getProperties() operation is a vector orarray of ModelObjects from the CDM, and a second array or vector containingthe names of the Teamcenter properties to retrieve for each ModelObject in thefirst array, as in:

getProperties(ModelObject[ ] objects, String[ ] attributes)

The return structure is a standard ServiceData structure that contains therequested ModelObjects with the requested attributes populated into themin addition to the attributes specified in the current ObjectPropertyPolicy.Returning both sets of attributes make it possible for the client application to usethe returned ModelObjects directly without worrying about merging the newattributes into the previously returned default set.

Note

See Policy impact on service performance regarding attribute or propertyexpansion. The same performance impacts discussed there pertain tothis operation as well. Attributes used by the client application shouldbe requested on an as-needed basis rather than prefetching a large list ofattributes in case the application may need them later. This is, of course,a trade-off between UI responsiveness and performance, and the balancebetween them often depends on the user’s expectations when using a specificclient application.


Performing common tasks using services

Uploading and downloading persistent filesWhile much of the information managed within Teamcenter is considered metadata,or data about things, it is often useful to associate bulk data with the metadata. Thisbulk data typically consists of various files containing product design geometry froma CAD application, specifications, analytical reports, and such. References to thesefiles are stored in Teamcenter in a construct called a dataset that is associated withan item in the Teamcenter database. The actual file content is persisted withinTeamcenter File Management System.

Uploading a file and attaching it to a dataset is a three-step process:

1. Request a ticket from Teamcenter File Management System (FMS).

2. Use the ticket to request FMS to upload and store the file.

3. Commit the file into the appropriate dataset using the commitDatasetFiles()operation.

An FMS ticket is a token that grants the holder permission to carry out a certainoperation, usually an upload or download of one or more files. The ticket generationprocess interfaces with the Teamcenter access management system to ensure thatonly authorized users can read, write, or modify bulk data and datasets using FMS.

For files referenced by datasets, the client application can call either:getDatasetWriteTickets(FileManagement.GetDatasetWriteTicketsInputData[ ] inputs)

or:getFileReadTickets(ImanFile[ ] files)

depending on whether it needs to perform a read or a write operation. Bothoperations are set-based, which allows multiple tickets to be requested at a singletime.

On a write, or upload, operation the uploaded files can be attached to datasets andcommitted to the Teamcenter database using:

commitDatasetFiles(FileManagement.CommitDatasetFileInfo[] commitInput)

For a complete explanation of FMS operations related to persistent files, see theTeamcenter File Management System documentation.


Chapter 5 Performing common tasks using services

Importing and exporting dataOften a client application wants to upload a local file and process its content intothe Teamcenter database, or extract some information from Teamcenter into afile and download the file for local use. The upload operation is called an importand the download operation is called an export. In either case, the file can beconsidered just a container which Teamcenter does not have to persist or track onceits contents have been transferred into or out of the system. These are referred toas transient files. Similarly to persistent files, transient files are transferred usingFile Management System (FMS).

To import data into Teamcenter using one or more transient files, the clientapplication needs to first obtain the appropriate write tickets from Teamcenter. Theclient application can pass the ticket, the local file names, and the name to importthe files as, to FMS.

Once the files are uploaded, the same tickets can be used to call the Teamcenteroperation that retrieves the files from FMS, perform the tasks necessary to parsethe file contents and process it into the Teamcenter database. Once the import iscomplete, FMS by default deletes the transient file, although the client applicationcan request that the file not be deleted by setting a flag on the ticket request.

The sequence of operations that is used to import data into Teamcenter is:getTransientFileTickets(someInputStructure[ ] inputs)

followed by a request to FMS to upload the files, and completed with:yourImportProcessor(yourInputStructure[ ] inputs)

Using transient files and FMS to export information from Teamcenter to a local fileis conceptually similar to the import use case, but in a slightly different sequence.The first step in an export operation is to call a Teamcenter service which performsthe data extraction, requests the appropriate FMS transient file tickets, writes thefiles to FMS, and returns the FMS tickets to the calling client.

With the returned tickets, the client application can request FMS to download thefiles. Once the download completes the client application can process the filesin whatever manner it chooses. By default, FMS deletes the transient file fromthe Teamcenter volume it was temporarily written to although there is an optionon the getTransientFileTickets() operation to request that the file not be deletedfrom the Teamcenter volume.

For a complete explanation of FMS operations related to transient files, see theTeamcenter File Management System documentation in the Configuration Guide.

For more information on specific mechanisms and file formats used in Teamcenterimport and export operations, refer to the documentation for the various Teamcenterapplications which expose import and export methods.


Index

A

Administration library . . . . . . . . . . . . . . 4-3AI

Library . . . . . . . . . . . . . . . . . . . . . . 4-20Service . . . . . . . . . . . . . . . . . . . . . . 4-20

AllocationsLibrary . . . . . . . . . . . . . . . . . . . . . . . 4-9Service . . . . . . . . . . . . . . . . . . . . . . 4-10

Application Integration . . . . . . . . . . . . 4-20Application Support . . . . . . . . . . . . . . . 4-9Applications . . . . . . . . . . . . . . . . . . . . 4-14

C

CAD library . . . . . . . . . . . . . . . . . . . . 4-22CalendarManagement

Library . . . . . . . . . . . . . . . . . . . . . . 4-11Service . . . . . . . . . . . . . . . . . . . . . . 4-11

Calling services . . . . . . . . . . . . . . . . . . . 3-3Classification

Library . . . . . . . . . . . . . . . . . . . . . . 4-14Service . . . . . . . . . . . . . . . . . . . . . . 4-15

Client data modelIntroduction . . . . . . . . . . . . . . . . . . . 2-4Using . . . . . . . . . . . . . . . . . . . . . . . . 3-5

Client libraries . . . . . . . . . . . . . . . . . . . 1-4Common tasks . . . . . . . . . . . . . . . . . . . 5-1Configuring services . . . . . . . . . . . . . . . 1-3Connection object . . . . . . . . . . . . . . . . . 3-2Core library . . . . . . . . . . . . . . . . . . . . . 4-4CredentialManager . . . . . . . . . . . . . . . . 3-1CrfReports

Library . . . . . . . . . . . . . . . . . . . . . . 4-12Service . . . . . . . . . . . . . . . . . . . . . . 4-12

D

Data import and export . . . . . . . . . . . . . 5-4DataManagement service . . . . . . . 4-5, 4-23Defining object property policies . . . . . . 3-10Distributed Systems . . . . . . . . . . . . . . 4-19DocumentManagement library . . . . . . . 4-18DocumentTemplate service . . . . . . . . . 4-18Downloading and uploading files . . . . . . 5-3

EEnabling services . . . . . . . . . . . . . . . . . 1-2Errors

Full . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Handling . . . . . . . . . . . . . . . . . . . . . . 3-7Partial . . . . . . . . . . . . . . . . . . . . . . . 3-7

Errors and exceptions . . . . . . . . . . . . . . 2-5Establishing a session . . . . . . . . . . . . . . 3-1Exporting and importing data . . . . . . . . 5-4

FFile upload and download . . . . . . . . . . . 5-3FileManagement service . . . . . . . . . . . . 4-6Full service errors . . . . . . . . . . . . . . . . . 3-8

GGetting started with services . . . . . . . . . 1-1

HHandling errors . . . . . . . . . . . . . . . . . . 3-7

IImporting and exporting data . . . . . . . . . 5-4Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Introducing services framework . . . . . . . 2-1IRM service . . . . . . . . . . . . . . . . . . . . . 4-6

LLibraries, client . . . . . . . . . . . . . . . . . . 1-4Logging on to Teamcenter . . . . . . . . . . . 3-2

MManagedRelations service . . . . . . . . . . . 4-7Message inputs and outputs . . . . . . . . . . 2-3Message transports . . . . . . . . . . . . . . . . 2-3

OObject property policies

PLM00076 A Teamcenter Services Guide Index-1

Index

Defining . . . . . . . . . . . . . . . . . . . . . 3-10Introduction . . . . . . . . . . . . . . . . . . . 2-5Performance . . . . . . . . . . . . . . . . . . 3-11Setting . . . . . . . . . . . . . . . . . . . . . . . 3-9Using . . . . . . . . . . . . . . . . . . . . . . . . 3-9

Organization of services . . . . . . . . . . . . . 4-1Outputs . . . . . . . . . . . . . . . . . . . . . . . . 2-3

PPartial errors . . . . . . . . . . . . . . . . . . . . 3-7Performance . . . . . . . . . . . . . . . . . . . . 3-11Platform . . . . . . . . . . . . . . . . . . . . . . . . 4-4Policies, object property . . . . . . . . . . . . . 3-9Prerequisites . . . . . . . . . . . . . . . . . . . . 1-1ProjectManagement library . . . . . . . . . 4-16

QQuery library . . . . . . . . . . . . . . . . . . . 4-13

RRequest and response . . . . . . . . . . . . . . 2-4RequirementsManagement

Library . . . . . . . . . . . . . . . . . . . . . . 4-17Service . . . . . . . . . . . . . . . . . . . . . . 4-17

Reservation service . . . . . . . . . . . . . . . . 4-7Retrieving basic item information . . . . . . 5-2

SSavedQuery service . . . . . . . . . . . . . . . 4-13ScheduleManagement service . . . . . . . 4-16Service exception errors . . . . . . . . . . . . . 3-8Services

Benefits . . . . . . . . . . . . . . . . . . . . . . 2-2Calling . . . . . . . . . . . . . . . . . . . . . . . 3-3Client libraries . . . . . . . . . . . . . . . . . 1-4Common tasks . . . . . . . . . . . . . . . . . . 5-1Configuring . . . . . . . . . . . . . . . . . . . . 1-3DataManagement . . . . . . . . . . . . . . . 4-5Enabling . . . . . . . . . . . . . . . . . . . . . . 1-2FileManagement . . . . . . . . . . . . . . . . 4-6Framework . . . . . . . . . . . . . . . . . . . . 2-1Getting started . . . . . . . . . . . . . . . . . 1-1IRM . . . . . . . . . . . . . . . . . . . . . . . . . 4-6ManagedRelations . . . . . . . . . . . . . . . 4-7Organization . . . . . . . . . . . . . . . . . . . 4-1Performance . . . . . . . . . . . . . . . . . . 3-11Prerequisites . . . . . . . . . . . . . . . . . . . 1-1Reservation . . . . . . . . . . . . . . . . . . . . 4-7Session . . . . . . . . . . . . . . . . . . . . . . . 4-8UserManagement . . . . . . . . . . . . . . . 4-3

Session service . . . . . . . . . . . . . . . . . . . 4-8Sessions . . . . . . . . . . . . . . . . . . . . . . . . 3-1Setting object property policies . . . . . . . . 3-9SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1StructureManagement service . . . . . . . 4-24System Administration library . . . . . . . . 4-3System Definition . . . . . . . . . . . . . . . . . 4-2

TTeamcenter

Logging on . . . . . . . . . . . . . . . . . . . . 3-2Sessions . . . . . . . . . . . . . . . . . . . . . . 3-1

UUploading and downloading files . . . . . . 5-3UserManagement service . . . . . . . . . . . . 4-3

Index-2 Teamcenter Services Guide PLM00076 A

Team Center Services

Documents

Transcript of Team Center Services