Team Center Services

Teamcenter 2007 Teamcenter Services Guide
Publication Number PLM00076 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.
Teamcenter Services Guide
PLM00076 A
Contents
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . Enable Teamcenter Services . . . . . . . . . . . . . Start Teamcenter Services . . . . . . . . . . . . . . . Teamcenter Services user interface . . . . . . . . Conguration required for Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 1-2 1-2 1-2 1-3
Introducing the Teamcenter Services framework . . . . . . . . . . . . . . . . . 2-1 What is SOA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Why Teamcenter Services is important . . . . . . . . . . . What you can do with Teamcenter Services . . . . . . . . Teamcenter Services advantage for your organization Teamcenter Services framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 2-2 2-2 2-2 2-3
Using Teamcenter Services framework components . . . . . . . . . . . . . . . 3-1 Establishing a Teamcenter session Calling services . . . . . . . . . . . . . Client data model components . . . Handling errors . . . . . . . . . . . . . Creating object property policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3-3 3-5 3-7 3-9
Teamcenter Services organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Teamcenter System Denition . . . . Teamcenter System Administration Teamcenter Platform . . . . . . . . . . Teamcenter Application Support . . Teamcenter Applications . . . . . . . . Teamcenter Distributed Systems . . Teamcenter Application Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 4-3 4-4 4-9 4-14 4-19 4-20
Performing common tasks using services . . . . . . . . . . . . . . . . . . . . . . . . 5-1 Retrieving basic item information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 Uploading and downloading persistent les . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 Importing and exporting data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1
Figures
3-1. Object property policy impact on performance . . . . . . . . . . . . . . . . . . . 3-12
PLM00076 A
Contents
3-2. 4-1.
Object project policy effect on execution time . . . . . . . . . . . . . . . . . . . . 3-13 Teamcenter service functional organization . . . . . . . . . . . . . . . . . . . . . 4-1
PLM00076 A
Chapter
Getting started
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Enable Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Start Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Teamcenter Services user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Conguration required for Teamcenter Services . . . . . . . . . . . . . . . . . . . . . . 1-3 Connecting a client application to the server . . . . . . . . . . . . . . . . . . . . . . 1-3 Using client libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
PLM00076 A
Chapter
Getting started
Teamcenter uses a service-oriented architecture (SOA) as one means to provide customers with the ability to quickly and easily develop task-specic clients, utilities, and system integrations using the power of the Teamcenter server. The Teamcenter Services operations are accessed through coarse-grained interfaces that minimize the amount of network trafc needed to accomplish any specic task. As such, Teamcenter is ideal for applications that were previously impractical because of slow network speeds or limited network bandwidth. Teamcenter Services ships with libraries and interfaces to build applications in Java, C++, and .NET, giving you the exibility to choose the technology that best ts with your particular environment and standards. Teamcenter Services also ships with WS-I compliant WSDL les for all operations, giving you further exibility and the condence that comes with supporting open industry standards.
Prerequisites
The 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 software development
PLM00076 A
1-1
Chapter 1
Getting started
Enable Teamcenter Services

Teamcenter Services is an integral architectural component of all Teamcenter 2007 and later servers, regardless of the deployment conguration (two-tier or four-tier) selected. The language-specic client libraries you must import into your development environment are available on the Teamcenter installation software distribution image. Libraries are included for Java, C++, and, .NET, as well as WSDL interfaces. All Teamcenter Services WSDLs are compliant with the WS-I Basic Prole. Although the Teamcenter 2007 and later servers include services interfaces in all deployment congurations as mentioned above, the provided client libraries are not equally appropriate for use in all deployments. In particular, the C# libraries are only available in four-tier (HTTP) deployments, while the Java and C++ libraries support both two-tier (IIOP) and four-tier (HTTP) deployments. While WSDL itself does not dene a transport, HTTP is the most common and the only one supported by Teamcenter Services. Note If you want to use the Teamcenter Services WSDL, you must install the optional Teamcenter Services WSDL/SOAP Support module to the Web tier installation 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 on Windows Servers Guide.
Start Teamcenter Services

Teamcenter Services is built right into the Teamcenter server and is an integral part of the Teamcenter 2007 and later architecture, so there is nothing specic that needs to be done to ensure that the Teamcenter Services interfaces are available for use.
Teamcenter Services user interface

Teamcenter Services is a programming interface or API exposed to application developers, rather than a program or application in and of itself, so it does not have a user interface.
1-2
PLM00076 A
Getting started
Conguration required for Teamcenter Services

Using the Teamcenter Services client libraries does not require any additional conguration of the Teamcenter server.
Connecting a client application to the server

The Teamcenter server does not require any additional conguration to allow your client application to use Teamcenter Services. The only conguration required is in your client application to tell it how to connect to the Teamcenter server. This is done with a host address using a specic 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 is executing on. port is the port number on the Teamcenter machine that is congured for communications. For HTTP communications, this is the port number on the Web application server. For example, if you are using WebLogic, the default value is 7001, or if you are using Apache Tomcat, the default value is 8080. For IIOP communications, this is the port dened by the CORBA ORB Endpoint. host is the network name of the machine that the Teamcenter server is executing on. server-id is the CORBA ID of the Teamcenter server. app-name is the application name that the Teamcenter Web tier processes are deployed under. The default value is tc, but may have been changed during the installation and conguration of the Teamcenter server software. service-port is the name of the Teamcenter Services operation being called. The optional URL query string wsdl returns the service WSDL, while the URL without the query string executes the service request.
In this conguration, all of the Teamcenter services are accessed using HTTP POST transactions.
PLM00076 A
1-3
Chapter 1
Getting started
Using client libraries

The Teamcenter Services client libraries are located on the Teamcenter installation CD-ROM, under the soa_client folder. This location includes the actual Teamcenter Services client libraries (Java, C++, and .NET), any libraries that they may be dependent 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 les are Eclipse RCP-ready plug-ins, and may be referenced in a standard Java JVM classpath, or as a plug-in to an Eclipse RCP application. C++ libtcsoalibrary-nametypes.dll Contain the XSD bindings for the service data structures. libtcsoalibrary-namestrong.dll Contain the strong model bindings of the service stubs. .NET TcSoalibrary-nameTypes.dll Contain the XSD bindings for the service data structures. TcSoalibrary-nameStrong.dll Contain the strong model bindings of the service stubs.
1-4
PLM00076 A
Getting started
The Teamcenter Services client libraries have the following dependencies: Java CORBA client (two-tier) jacorb.jar avalon-framework-4.1.5.jar logkit.jar tcgatewaystubs.jar commons-httpclient-2_0_2.jar Xerces version 2.6.2: resolver.jar xercesImpl.jar xml-apis.jar xmlParserAPIs.jar JAXB version 1.0.5 (JWSDP 1.6): jaxb-api.jar jaxb-impl.jar jaxb-libs.jar jaxb-xjc.jar jax-qname.jar namespace.jar relaxngDatatype.jar xsdlib.jar Logging commons-logging.jar log4j-1.2.8.jar Not applicable Not applicable C++ ACE.dll TAO.dll .NET Not available
HTTP client (four-tier) XML
libcurl.dll Xerces version 2.6.2:
TcSoaClient.dll System.Xml .NET Framework Version 2.0
icudt32.dll icuin32.dll icuuc32.dll xalan19.dll xerces260.dll
PLM00076 A
1-5
Chapter 1
Getting started
On Microsoft Windows the following compiler and linking options must be set when using the Teamcenter Services C++ libraries: C++ Compiler Options Additional Include Directory Preprocessor Denitions: Enable Run-Time Type Info: Force Includes: Link Options Additional Library Directory Additional Dependencies The libs folder in the soa_ client directory distribution. /LIBPATH:"drive\soa_client\cpp\libs\wnti32" libtcsoacommon.lib libtcsoaclient.lib libtcsoacore.lib (Any other service libraries your application depends on) The include folder in the soa_client distribution. /I drive\soa_clients\cpp\include /D IPLIB /GR /FI msvcpragmas.h
1-6
PLM00076 A
Chapter
Introducing the Teamcenter Services 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 . . . . . . . . . . . . . . . Available message transports . . . . . . . . . . . . . . Common message structures (input and output) Request and response interaction patterns . . . . Client data model . . . . . . . . . . . . . . . . . . . . . . Errors and exceptions . . . . . . . . . . . . . . . . . . . Object property policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 2-3 2-3 2-4 2-4 2-5 2-5
PLM00076 A
Chapter
What is SOA?
Service-oriented architecture, or SOA, refers to a style or pattern used in the development of enterprise-class business applications. Traditional business application development has followed a purpose-built paradigm that is now perceived as being inexible and incapable of evolving at the same rapid pace that business markets and processes are now changing. Almost by denition, then, an SOA needs to provide exibility and the opportunity for business applications to keep pace with changes in the global business climate. Teamcenter Services use of SOA utilizes contract-based, coarse-grained interfaces to expose Teamcenter functionality in a standard way that can be used by Teamcenter client applications, other UGS applications, and customers in-house applications. The most important characteristics of SOA that allow it to meet these fundamental objectives are: Contract-based interfaces SOA promotes the use of abstract interfaces independent of underlying business logic implementations. These interfaces represent a contract between clients and the business applications. As long as the client makes a proper request for a service, the server honors it and returns a response in the format specied in the contract. The SOA contract helps to uncouple client and server development activities and allows them to evolve independently so long as the contract remains intact. Coarse-grained interfaces SOA interfaces also tend to be coarse-grained, in the sense that they ideally represent a complete business transaction. The client makes a request for some type of work to be done; the server executes the full operation without any intervening conversation with the client, and then sends back a fully-complete response to the client. This results in fewer remote calls to API and brings about a nonchatty interface.
PLM00076 A
2-1
Chapter 2
Single entry point to business logic Once a service is exposed through SOA, it is immediately available to all clients. Because the service is contract-based, the server logic does not need to know anything about the client requesting the service, which allows new client technologies to be adopted without changing the service or invalidating other clients using the service.
Why Teamcenter Services is important

Teamcenter Services provides the underpinnings for high performance, scalable, WAN-friendly applications to a degree never before available. Its contract-based interfaces ensure stability and longevity for applications built using Teamcenter services.
What you can do with Teamcenter Services

Services can be used to create loosely-coupled integrations with Teamcenter, regardless of the programming language standards and operating environments prevalent in your organization. You can use services to integrate Teamcenter with the programming language of your choice. Teamcenter Services includes client libraries for Java, .NET and C++, as well as WS-I compliant WSDL so it can be integrated with virtually any other, previously incompatible, legacy technology. Services can also be used both for interactive, end-user integrations as well as a noninteractive, system-to-system integrations.
Teamcenter Services advantage for your organization

Teamcenter Services provides service interfaces that are both language and technology independent. This means that all of your applications can use the same interfaces to backend systems, resulting in lower system and maintenance costs for your organization. The coarse-grained nature of the Teamcenter services interfaces means more work gets done in a single request-response cycle, making application performance over high-latency networks possible. Services also provides a client side data model (CDM) with added support for SSO and FMS, which takes care of all the underlying requirements to talk to the server. Your application developers can concentrate on real functionality that helps your business without getting caught up in low-level infrastructure development. The inclusion of industry standard WSDL Web service interfaces, which are compliant to the WS-I Basic Prole, enables easier integration with supplier and partner systems without having to worry about proprietary bridges and complex data transforms being built into every application.
2-2
PLM00076 A
Teamcenter Services framework

The 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 Teamcenter congurations. An autogenerated client data model that exposes the Teamcenter server data model to service-based client applications.
The actual Teamcenter service implementations are an integral part of the Teamcenter Server business logic.
Available message transports

Client applications using Teamcenter services can be congured to take advantage of different communication protocols and message transports to connect to the Teamcenter server. In two-tier Teamcenter congurations, where an instance of the Teamcenter server process actually executes on the same end-user computer as the client application, a tight, CORBA-based integration with the Java and C++ client libraries can be used. In four-tier Teamcenter congurations, where the client and server processes execute on different computers separated by a network, there is a wider variety of communication 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 characteristics to help ensure consistency in how the operation signatures look to developers, as well 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 of applications. The set-based nature of the services can be seen in operation signatures that take as input an array or vector of structures. This allows the client application developer to request a similar operation on multiple data model items with a single call to the server. Being broadly-applicable is the second noticeable pattern in the way operations are implemented. For example, even though the attributes necessary in creating different types of business items can vary widely, the mechanics of doing so is very similar form an end-user standpoint. A single Teamcenter service can usually be applied to multiple business object types. As a result, the overall set of operations that a client developer needs to learn is greatly reduced. This pattern also provides a clean mechanism for extending the type of business objects that can be acted upon without having to introduce new operations with slightly different signatures for every one.
PLM00076 A
2-3
Chapter 2
While those two patterns, set-orientation and broad applicability are the default approach to creating service operations, there are places where explicit operations on some business items are provider for the developers convenience, or the needs of specic, common usages of the service. This approach provides a balance between completely generalized operations and the need for developer convenience in working through certain use cases.
Request and response interaction patterns

A typical request/response cycle used with Teamcenter services requires the following steps: 1. Populate a set of structures representing the business items that you want to request an operation on. 2. Gather the populated structures into a vector or array as appropriate for the client 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. Typically this means listening for updates from the client data model ModelManager component and updating the applications user interface to reect the results of the operation.
Client data model

The language-specic services client libraries contain a client data model (CDM) component that acts as a local data store for Teamcenter data returned by service method calls. If the client application is using the loosely typed client libraries, the client data model is populated with instances of ModelObject objects, a generically-typed list of a name/value pairs representing the objects properties. If the client is using the strongly-typed client libraries, the client data model is populated with typed objects that correspond one-to-one with their server-side object type. If the specic server-side type does not exist on the client, the nearest available parent type is constructed. All properties associated with the type are still available to the 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 data model components.
2-4
PLM00076 A
Errors and exceptions

Set-based operations take as input a list of business objects and associated parameters that control how the Teamcenter server should process each object. The result 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 in the ServiceData object, and the object properties themselves in operation-specic structures. 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 object contains appropriate ErrorStack entries for each failed item or operation. When an operation fails, a service exception is generated and returned to the calling client and must be handled by the application logic which called the service operation.
Object property policies

The object property policy denes which properties are included for a given object type when returning objects to the client. The policy is used by the Teamcenter Services framework to automatically and uniformly inate the properties of objects contained in the ServiceData object of the services returned data structure. A Teamcenter server installation is deployed with a default policy plus any number of specic policies dened by the different client applications. Each installed application using Teamcenter services typically has one or more policies installed on the server. For more information, see Creating object property policies.
PLM00076 A
2-5
Chapter
Using Teamcenter Services framework components
Establishing a Teamcenter session CredentialManager interface . Connection object . . . . . . . . . Logging on to Teamcenter . . . ExceptionHandler interface . . Code example . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
3-1 3-1 3-2 3-2 3-2 3-3
Calling services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Client data model components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 Handling errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partial errors for Teamcenter model data . . . . . . . . . . . . . . . . Partial errors accessed directly from the ServiceData object Partial errors accessed from a model manager listener . . . . Partial errors for non-Teamcenter model data . . . . . . . . . . Full service errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating object property policies . . . . . . Setting the current policy . . . . . . . . Dening a policy . . . . . . . . . . . . . . . Policy impact on service performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 3-7 3-7 3-7 3-8 3-8 3-9 3-9 3-10 3-11
PLM00076 A
Chapter
Establishing a Teamcenter session

There are several steps to establishing a Teamcenter session for your client application: 1. Instantiate a CredentialManager object. 2. Instantiate a Connection object. 3. Call the SessionService.login() operation. 4. Handle exceptions.
CredentialManager interface
The rst step in establishing a Teamcenter session is to instantiate a CredentialManager object. The Teamcenter Services framework includes a CredentialManager interface that the client application developer must create an implementation for. It is the responsibility of the client application developer to decide how best to implement the CredentialManager interface in the context of their application. The CredentialManager implementation may cache credentials (typically user name and password), or a Teamcenter SSO token) gathered from the user to allow for silent re-authentication in the case of dropped communications or session time-outs. Depending on security constraints within your organization the CredentialManager implementation can prompt the user for credentials if there is an issue with the validity of their session. In maintaining a session between the client application and Teamcenter, the session for your client application may terminate at any time, most commonly because of inactivity for more than the maximum period set by the site administrator, or a communications network failure. When this occurs, the client application needs to re-authenticate. Instead of having the client application catch and react to an InvalidUser exception for every service request, the Teamcenter Services framework does this automatically. When the Teamcenter server does return an InvalidUser exception, the client framework uses the CredentialManager interface in the Connection object to get the users credentials and send the SessionService.login() service request to re-establish a session. Once validated, the service request that originally caused the InvalidUser exception is resubmitted automatically by the Teamcenter Services framework.
PLM00076 A
3-1
Chapter 3
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 single user connecting to a single server, the client application needs to instantiate and maintain a single instance of the Connection object. It is this Connection object that is used to instantiate the appropriate service stubs as service operations are invoked by the client application. Even though the Connection object is instantiated, no communication is made on the congured Connection until a Teamcenter Services operation is actually invoked.
Logging on to Teamcenter
Before any service operation can be invoked, the user must be authenticated. This is done through the SessionService.login operation. Whenever possible, use the SessionService.logout operation to explicitly log a user off of Teamcenter when they exit your application, or when the user does not need to use the Teamcenter session any longer. This is preferable to allowing the session to time-out due to inactivity. Waiting for the server to time out the session can cause server resources to be held unnecessarily.
ExceptionHandler interface
Similar to the InvalidUser exception handled by the CredentialManager interface, any service request can also throw an InternalServer exception. An InternalServer exception is most commonly caused by a conguration, communication, or programming error. To alleviate the need for the client application to catch this exception with every service request, your client application can implement the ExceptionHandler interface and add it to the Connection object. Your client applications implementation of the ExceptionHandler interface can determine how these exceptions are handled. The handler can display the error message, prompt the user to x the problem and send the request again, throw a RunTimeException exception, or exit the application.
3-2
PLM00076 A
Code example
The following code example puts together the four steps for establishing a session with the Teamcenter server:
CredentialManager credentialMgr = new YourAppCredentialManager(); = new YourAppExceptionHandler(); ExceptionHandler expHandler 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.getService(connection); SavedQueryService queryService 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 services
Invoking a Teamcenter service from the available client bindings is generally the same and only differs in language syntax. Services are accessed through an abstract class or interface for what is called a base service. The actual service request goes through a stub specic to the transport protocol (HTTP, IIOP, and so on) and binding style (SOAP, REST, and so on) that the client application is congured to use. The client application is responsible for obtaining the correct stub implementation through the static getService() method on the base service class using information from the Connection object. As long as the run-time stub is instantiated by the Teamcenter services framework the application code can remain agnostic to the actual transport protocols and binding styles congured. Following are examples of instantiating a base service and invoking an operation in three different language/model bindings, with bold text indicating the differences between the language/model bindings. Java strongly typed data model:
import com.teamcenter.services.strong.core.DataManagementService; // Instantiate the service stub DataManagementService service = DataManagementService.getService( connection );
// Invoke the service CreateFoldersResponse out = service.createFolders( folders, container, "child" );
Java loosely typed data model:

import com.teamcenter.services.loose.core.DataManagementService; // Instantiate the service stub DataManagementService service = DataManagementService.getService( connection );
// Invoke the service CreateFoldersResponse out = service.createFolders( folders, container, "child" );
PLM00076 A
3-3
Chapter 3
C++ strongly typed data model:

include <teamcenter/services/core/DataManagementService.hxx> // Instantiate the service stub DataManagementService* service = DataManagementService.getService( connection ); // Invoke the service CreateFoldersResponse out = service->createFolders( folders, container, "child");
.NET strongly typed data model:

using Teamcenter.Services.Strong.Core; // Instantiate the service stub DataManagementService service = DataManagementService.GetService( connection );
// Invoke the service CreateFoldersResponse out = service.CreateFolders( folders, container, "child" );
3-4
PLM00076 A
Client data model components

The key components of the client data model are the ServiceData object, the ModelManager object, and the ErrorStack object. The ServiceData object is a collection of Teamcenter data model objects sorted into lists: created, deleted, updated, or plain. These lists are populated as part of executing an operation on the Teamcenter server and passed back as part of the response to each service request. If the client is using the loosely typed language binding, the client data model (CDM) is populated by ModelManager with instances of the ModelObject class, collectively called model objects. The model objects represent 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 is populated by the ModelManager object with object instances of the same type that the object has on the Teamcenter server. If the specic type does not exist on the client, the nearest available parent type is constructed. Client applications can directly access the four ServiceData list structure using methods built into the ServiceData object. Methods are available to return the number of object references in each list as well as to return the object at a specic index 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 data for(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 specific if(singleItem instanceof GeneralDesignElement) { GeneralDesignElement gde = (GeneralDesignElement)singleItem; System.out.println("Is Frozen: "+gde.getIs_frozen()); //POMObject System.out.println("Cardinality: "+gde.getCardinality());//GDE object } }
Each list within the ServiceData object can be accessed by substituting the sizeOfCreatedObjects() and getCreatedObject(i) methods in the sample with the appropriate one of sizeOfDeletedObjects(), sizeOfChangedObjects(), or sizeOfPlainObjects() and getDeletedObjects(), getChangedObjects(), or getPlainObjects(). While this approach to retrieving returned data is useful in some cases, a more convenient listener-based approach is provided by the ModelManager object.
PLM00076 A
3-5
Chapter 3
The ModelManager object is member of the Connection object that is in use. ModelManager serves as an intermediary between local object storage and the wire-level representations of Teamcenter objects. Its most signicant feature from an application developers perspective is its exposure of listeners that can be 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 error listeners, each of which are invoked by ModelManager as data corresponding to each listener type is returned from the server. The following example shows the use of a ChangeListener component:
modelManager.addChangeListener( new ChangeListener() { // The client application can implement instances of the // ChangeListener to take appropriate action when object have changed public void modelObjectChange( ModelObject[] changedObjs ) { for (int i = 0; i < changedObjs.length; i++) { // The ModelManager will provide a list of ModelObject if(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 in the same manner for the ChangeListener. Client application developers should use the ModelManager listeners unless there is a specic need to access the data either directly from the ServiceData object, or directly from the ModelManager object. The ModelManager object also exposes a method to directly retrieve objects instances by their UID. In general, a client application has little use for accessing model objects in this manner; the application gets the object directly from the ServiceData 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 is operating with the strongly typed or loosely typed bindings; the only difference is in the type of the returned object.
3-6
PLM00076 A
Handling errors
Teamcenter Services can handle partial or full errors.
Partial errors for Teamcenter model data

The majority of Teamcenter service operations are set-based. The operation may succeed on some of the objects in the set while failing on others. To notify the client application of the failure on the subset of input objects, a PartialErrors structure is included in the ServiceData. The client application has several options for accessing 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 0 or more error stacks on it. Each error stack has a list of one or more errors that contributed to this particular failed action. The service implementation may also set a client ID or associated model object; these are provided to help the client application 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 data for(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 client application when partial errors have been returned from any Teamcenter service operation. The client application may create any number of implementation of this listener. The model manager invokes each instance of the listeners as appropriate data 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 it System.out.println("Error for client Id "+ errorStack.getClientId()); Modelbject assocObj = errorStack.getAssociatedObject(); // Each Partial Error may have 1 or more sub-errors String[] messages = errorStack.getMessages(); for(int j=0; j< messages.length;j++) { System.out.println( messages[j] ); } } } });
PLM00076 A
3-7
Chapter 3
Partial errors for non-Teamcenter model data For set-based service operations that do not return a ServiceData object, partial errors 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++) { System.out.println( messages[j] ); } }
Full service errors

A ServiceException exception is thrown only when the implementation of service operation expects the client application to do special processing when the operation fails as a whole (not only partial errors). For service operations that dene that ServiceException may be thrown, the client application must surround these service requests with a try/catch block:
try { // Execute the service request String out = fooService.operationBar ( ); System.out.println("Service out:"+out); } // The service may have thrown an error catch (ServiceException e) { String[] messages = e.getMessages(); for (int i = 0; i < messages.length; i++) { // The Error may have 1 or more sub-errors System.out.println( messages[i] ); } }
3-8
PLM00076 A
Creating object property policies

The object property policy denes which properties are included for a given object type when returning objects to the client. The policy is used by the Teamcenter Services framework to automatically and uniformly inate the properties of objects contained in the service data of an operations returned data structure. A Teamcenter server deployment includes a default policy provided by the framework along with any number of specic policies dened by the Teamcenter client applications themselves. Each installed application using Teamcenter services typically has one or more policies dened on the Teamcenter server.
Setting the current policy

The client application can specify a policy for the Teamcenter Services framework to enforce by calling the Session.setObjectPropertyPolicy() operation. If the client application does not specify a policy, the Teamcenter Services framework uses the default application policy. Client applications are responsible for dening and maintaining at least one object property policy. Policies are congured in XML les. They are stored in a Teamcenter volume in a $TC_DATA/soa/policies/policy-name.xml le. Once a policy is set using Session.setObjectPropertyPolicy(), it is enforced for the duration of the current session, or until the next Session.setObjectPropertyPolicy() request is received. The reserved policy called 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 the name of the current policy as well as the previous policy. Providing both makes it easier for application developers to set a policy for a single operation and then quickly restore the previous policy without having to store the previous policy name ahead of time.
PLM00076 A
3-9
Chapter 3
Dening a policy
The object property policy is a list of Teamcenter classes and/or types and properties associated with those classes and types. The properties dened in a parent class are inherited by child classes. The policy syntax supports referencing Teamcenter preferences to specify additional properties. Each policy le has a customization point to allow site administrators to add additional types and properties without having to edit the original delivered policy. The following code is an example of a simple policy conguration:
<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 values returned for the properties dened under those types but also the properties dened under the WorkspaceObject object, because the WorkspaceObject object is the parent for both Item and ItemRevision. BOMLine objects have property values for the two properties explicitly named, and all of the property names dened in the PortalPSEColumnsShownPref preference variable. Optionally the Property element can include the withProperties attribute. By default, the object property policy is applied only to the objects explicitly returned by the service implementations. If the service returns a User object and the home_folder property is part of the policy, the referenced home_folder object is added to the return data, but without any associated properties. By adding withProperties="true" to the home_folder property, properties for home folder are also returned. Additional types and properties specied in the MySitePolicy.xml le are included in this policy.
3-10
PLM00076 A
Policy impact on service performance

As a Teamcenter client application developer, you should not need to be concerned with what is happening within service requests. The one major exception to that arises from the fact that an ill-conceived or poorly implemented object property policy can seriously impact system overhead and application performance. In a more traditional programming model, the functionality of the object property policy would be included in the business logic of a service, where the business logic would not only assemble a list of model objects to return, but also the property values associated with each of those objects. In the Teamcenter Services environment, the business logic only determines which objects are returned; by default, those objects are returned without any associated properties. It is the Teamcenter Services frameworks enforcement of the object property policy that retrieves the object properties and adds them to the operations return structure. By allowing the client application developer to choose what types and properties make up an object property policy and providing the ability to set which policy is being enforced gives the client application large control over the amount of data returned by an operation.
PLM00076 A
3-11
Chapter 3
Figure 3-1 compares two service requests each returning 250 objects. The rst service request uses an object property policy that only denes one property for the given object type, for a total of 250 properties being returned, while the second service requests uses an object property policy that denes 10 properties for the given object type, for a total of 2,500 properties being returned. The red section of the bar shows the relative time spent inating properties. This is where the Teamcenter Services framework uses the current policy to retrieve the desired properties for each object in the ServiceData object.
Relative Times in Service Call Stack (250 Objects) 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
1 Property/Object 10 Properties/Object Client Parse XML
Server Serialize XML
Server Inflate Properties
Business Logic
Web Tier
Figure 3-1. Object property policy impact on performance
3-12
PLM00076 A
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 properties and others have 15. All that matters is the total number of properties that the property policy manager of the Teamcenter Services framework needs to retrieve from the database and add to the service response. Figure 3-2 shows a very linear increase in execution time with the increase in total number of properties returned.
Inflate Properties Execution Times
2500
2000
Milliseconds
1500
1000
500
0 0 250 500 750 1000 1250 1500 1750 2000 2250 2500
Total Number of Properties
Figure 3-2. Object project policy effect on execution time Applications should use policies that return the data needed for the use cases they support and be careful not to retrieve too many properties in case they may be needed in a subsequent operation.
PLM00076 A
3-13
Chapter
Teamcenter Services organization
Teamcenter System Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Teamcenter System Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Administration library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 UserManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Teamcenter Platform . . . . . . . . . Core library . . . . . . . . . . . . . DataManagement service . FileManagement service . IRM service . . . . . . . . . . ManagedRelations service Reservation service . . . . . Session service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 4-4 4-5 4-6 4-6 4-7 4-7 4-8 4-9 4-9 4-10 4-11 4-11 4-12 4-12 4-13 4-13 4-14 4-14 4-15 4-16 4-16 4-17 4-17 4-18 4-18
Teamcenter Application Support . . . Allocations library . . . . . . . . . . . Allocations service . . . . . . . . CalendarManagement library . . CalendarManagement service CrfReports library . . . . . . . . . . . CrfReports service . . . . . . . . Query library . . . . . . . . . . . . . . SavedQuery service . . . . . . .
Teamcenter Applications . . . . . . . . . . . . . Classication library . . . . . . . . . . . . . Classication service . . . . . . . . . . ProjectManagement library . . . . . . . . ScheduleManagement service . . . . RequirementsManagement library . . . RequirementsManagement service DocumentManagement library . . . . . . DocumentTemplate service . . . . . .
Teamcenter Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19 Teamcenter Application Integration . . AI library . . . . . . . . . . . . . . . . . . AI service . . . . . . . . . . . . . . . CAD library . . . . . . . . . . . . . . . . DataManagement service . . . . StructureManagement service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20 4-20 4-20 4-22 4-23 4-24
PLM00076 A
Chapter
Teamcenter services APIs are organized as a hierarchy of functional areas, libraries, services, and operations. API documentation can be found on the Teamcenter installation 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 functional areas, a small number of coarse-grained categories into which the various API code libraries are organized. A functional area can have any number of libraries within it. A library corresponds to a compiled code artifact such as a DLL on Windows, or an SO on other platforms, and contains one or more services relating to particular Teamcenter functionality or capabilities. Within each service are a set of one or more operations which make up the actual callable methods on the API.
Applications
Classification::ClassificationService DocumentManagement::DocumentTemplateService ProjectManagement::ScheduleManagementService RequirementsManagement::RequirementsManagementService
Application Integration
AI::AIService CAD::DataManagementService CAD::StructureManagementService
Application Support
Allocations::AllocationService CalendarManagement::CalendarManagementService Query::SavedQueryService Reports::CrfReportsService
System Administration
Core::UserManagement
System Definition Platform

Core::DataManagementService Core::FileManagementService Core:IRMService Core::ManagedRelationService Core::ReservationService Core::SessionService
Figure 4-1. Teamcenter service functional organization
PLM00076 A
4-1
Chapter 4
Teamcenter System Denition

The System Denition functional area contains the functionality used by the Teamcenter Business Modeler IDE and other tools to dene and customize a particular Teamcenter installation or system deployment. There is not any functionality in these libraries that is used for day-to-day administration or end-user activities. There are currently no public services or operations exposed for Teamcenter System Denition.
4-2
PLM00076 A
Teamcenter System Administration

The System Administration library functional area contains the libraries related to the day-to-day administration of a Teamcenter system or deployment. Along with the Teamcenter Platform services and Teamcenter Application Support services, the operations exposed can be used in a variety of custom administration scenarios that may be important to your organization.
Administration library
The Administration library currently exposes a single service, UserManagement. The following les are used for the Administration library: Java TcSoaAdministrationTypes.jar TcSoaAdministrationStrong.jar TcSoaAdministrationLoose.jar C++ libtcsoaadministrationtypes.dll libtcsoaadministrationstrong.dll C# TcSoaAdministrationTypes.dll TcSoaAdministrationStrong.dll UserManagement service The UserManagement service currently exposes a single service, createDisciplines. Following are the namespaces for the UserManagement service: Java
com.teamcenter.services.strong.core.UserManagemtService
C++
Teamcenter::Services::Core::UserManagementService
C#
Teamcenter.Services.Strong.Core.UserManagementService
PLM00076 A
4-3
Chapter 4
Teamcenter Platform
The Teamcenter Platform functional area contains those libraries, services, and operations that are considered fundamental to how data is stored, managed, and accessed in Teamcenter. These libraries as such are independent of any particular Teamcenter application space. They make up the core of functionality that all other application areas are built upon.
Core library
The following les are used for the Core library: Java TcSoaCoreTypes.jar TcSoaCoreStrong.jar TcSoaCoreLoose.jar C++ libtcsoacoretypes.dll /libtcsoacorestrong.dll C# TcSoaCoreTypes.dll TcSoaCoreStrong.dll The Core library currently contains ve services: DataManagement FileManagement IRM ManagedRelations Reservation Session
4-4
PLM00076 A
DataManagement service The DataManagement service exposes operations that are common to virtually all standard and custom Teamcenter applications, including the creation, and deletion of items to be managed, relating items to each other, organizing them into folders, attaching bulk data to items, and specifying the ownership and identication of managed items. It also includes operations for specifying item properties and identifying where items are referenced or used by other items throughout the system. Following are the namespaces for the DataManagement service: Java
com.teamcenter.services.strong.core.DataManagemtService
C++
Teamcenter::Services::Core::DataManagementService
C#
Teamcenter.Services.Strong.Core.DataManagementService
This service contains the following operations: changeOwnership createDatasets createFolders createItems createOrUpdateForms createRelations deleteObjects deleteRelations generateItemIdsAndInitialRevisionIds generateRevisionIds generateUID getDatasetCreationRelatedInfo getItemCreationRelatedInfo getItemFromId getProperties moveToNewFolder refreshObjects revise setDisplayProperties setProperties whereReferenced whereUsed
PLM00076 A
4-5
Chapter 4
FileManagement service The Teamcenter Platform FileManagement service exposes operations used in uploading and downloading persistent les associated with items managed in the Teamcenter system, or transient les which represent either the input to, or the output from, various Teamcenter import/export functions. Following are the namespaces for the FileManagement service: Java
com.teamcenter.services.strong.core.FileManagemtService
C++
Teamcenter::Services::Core::FileManagementService
C#
Teamcenter.Services.Strong.Core.FileManagementService
This service contains the following operations: commitDatasetFiles) getDatasetWriteTickets getFileReadTickets getTransientFileTicketsForUpload IRM service The Identity and Rights Management (IRM) service exposes operations used to set or retrieve information about a users privileges on the system, or their privileges regarding accessing and manipulating items or types of items within Teamcenter. Following are the namespaces for the IRM service: Java
com.teamcenter.services.strong.core.IRMService
C++
Teamcenter::Services::Core::IRMService
C#
Teamcenter.Services.Strong.Core.IRMService
This service contains the following operations: checkAccessorsPrivileges getEffectiveACLInfo getExtraProtectionInfo removeAccessor setPrivileges
4-6
PLM00076 A
ManagedRelations service Managing the formal relationships between business items is a primary reason for implementing Teamcenter, so it is natural that Teamcenter has operations specically geared towards creating and managing these formal relations. The ManagedRelations service exposes operations that can be used to create relationships between items, modify existing relationships between items in the system, and return information that can be used to generate traceability reports which show those relationships. Following are the namespaces for the ManagedRelations service: Java
com.teamcenter.services.strong.core.ManagedRelationsService
C++
Teamcenter::Services::Core::ManagedRelationsService
C#
Teamcenter.Services.Strong.Core.ManagedRelationsService
This service contains the following operations: createRelation getTraceReport modifyRelation Reservation service The Reservation service exposes operations that are used to control the concurrent revisioning of items in the system. Very much like a source code control system, the Teamcenter Reservation service allows items to be checked out to be worked on, and later checked back into the system as a new revision of the item. An operation for retrieving an items reservation history is also available in this service. Following are the namespaces for the Reservation service: Java
com.teamcenter.services.strong.core.ReservationService
C++
Teamcenter::Services::Core::ReservationService
C#
Teamcenter.Services.Strong.Core.ReservationService
This service contains the following operations: cancelCheckout checkin checkout getReservationHistory
PLM00076 A
4-7
Chapter 4
Session service The Session service exposes operations that can be used to establish a client or user session with the Teamcenter server. A session can be established through a standard username/password style logon operation, or through the use of Teamcenter Security Services (TSS or TcSSO) credentials. Once a session is established, information about 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 a session the supplied logout operation should be performed to inform the Teamcenter server that this session is no longer needed. Following are the namespaces for the Session service: Java
com.teamcenter.services.strong.core.SessionService
C++
Teamcenter::Services::Core::SessionService
C#
Teamcenter.Services.Strong.Core.SessionService
This service contains the following operations: getAvailableServices getGroupMembership getPreferences getSessionGroupMember getTCSessionInfo login loginSSO logout setObjectPropertyPolicy setPreferences setSessionGroupMember
4-8
PLM00076 A
Teamcenter Application Support

The Application Support functional area contains the libraries and services that serve the common needs of day-to-day, end user applications. The services and operations that are made available here support standard mechanisms for system queries and searches, report denition and generation, creation and maintenance of calendars used in project management and workow applications.
Allocations library
The Allocations library currently contains a single service, Allocations, that exposes operations used to manage complex, one-to-many and many-to-one relationships between items in the Teamcenter system. The following les are used for the Allocations library: Java TcSoaAllocationsTypes.jar TcSoaAllocationsStrong.jar TcSoaAllocationsLoose.jar C++ libtcsoaallocationstypes.dll libtcsoaallocationsstrong.dll C# TcSoaAllocationsTypes.dll TcSoaAllocationsStrong.dll
PLM00076 A
4-9
Chapter 4
Allocations service The Allocations service exposes operations that are used to establish and maintain complex, one-to-many, many-to-one, and many-to-many relationships between items in the Teamcenter system. Common uses for allocations include requirements management, systems engineering, and other application domains that require these types of complex relationships. These operations can also be used in product conguration applications to ensure that design constraints and mandatory selections on product options are satised. Following are the namespaces for the Allocations service: Java
com.teamcenter.services.strong.allocations.AllocationService
C++
Teamcenter::Services::Allocations::AllocationService
C#
Teamcenter.Services.Strong.Allocations.AllocationService
This service contains the following operations: addAllocationLines changeAllocatedBOMWindows changeAllocationContext changeICContext closeAllocationWindow createAllocationContext deleteAllocationLines ndAllocatedBOMViews ndAllocationContexts getBOMViews modifyAllocationLines openAllocationWindow saveAllocationWindow
4-10
PLM00076 A
CalendarManagement library
The CalendarManagement library currently contains a single service, CalendarManagement. The following les are used for the CalendarManagement library: Java TcSoaCalendarManagementTypes.jar TcSoaCalendarManagementStrong.jar TcSoaCalendarManagementLoose.jar C++ libtcsoacalendarManagementypes.dll libtcsoacalendarManagementstrong.dll C# TcSoaCalendarManagementTypes.dll TcSoaCalendarManagementStrong.dll CalendarManagement service The CalendarManagement service exposes operations used in the creation and maintenance of calendars used in scheduling, project management, and workow applications. The exposed operations provide standard create, modify, update, and delete capabilities, as well as the general ability to retrieve calendars for use in applications. Following are the namespaces for the CalendarManagement service: Java
com.teamcenter.services.strong.CalendarManagement.CalendarManagementService
C++
Teamcenter::Services::CalendarManagement::CalendarManagementService
C#
Teamcenter.Services.Strong.CalendarManagement.CalendarManagementService
This service contains the following operations: createTCCalendars deleteTCCalendars getTCCalendars modifyTCCalendars updateTCCalendars
PLM00076 A
4-11
Chapter 4
CrfReports library
The Common Reporting Framework library, CrfReports, contains a single service, also called CrfReports. The following les are used for the CreReports library: Java TcSoaReportsTypes.jar TcSoaReportsStrong.jar TcSoaReportsLoose.jar C++ libtcsoareportstypes.dll libtcsoareportsstrong.dll C# TcSoaReportsTypes.dll TcSoaReportsStrong.dll CrfReports service The CrfReports service exposes operations that allow for the denition and generation of Teamcenter reports in a standard fashion for all Teamcenter applications. Operations are also available to autogenerate report identiers and to retrieve existing report denitions that meet the users input criteria. Following are the namespaces for the CrfReports service: Java
com.teamcenter.services.strong.Reports.CrfReportsService
C++
Teamcenter::Services::Reports::CrfReportsService
C# Teamcenter.Services.Strong.Reports.CrfReportsService
This service contains the following operations: createReportDenition generateReport generateReportDentionIds getReportDenitions
4-12
PLM00076 A
Query library
The Teamcenter Query library currently contains a single service called the SavedQuery service. The following les are used for the Query library: Java TcSoaQueryTypes.jar TcSoaQueryStrong.jar TcSoaQueryLoose.jar C++ libtcsoaquerytypes.dll libtcsoaquerystrong.dll C# TcSoaQueryTypes.dll TcSoaQueryStrong.dll SavedQuery service The SavedQuery service exposes operations that allow the creation, execution, and maintenance of predened queries stored within the Teamcenter system. Teamcenter ships with a wide range of predened queries covering many common product data management use cases. Customer administrators and end users can create additional queries that can be saved into the system and used by other end users. Following are the namespaces for the SavedQuery service: Java
com.teamcenter.services.strong.Query.SavedQueryService
C++
Teamcenter::Services::Query::SavedQueryService
C# Teamcenter.Services.Strong.Query.SavedQueryService
This service contains the following operations: describeSavedQueries executeSavedQuery getSavedQueries
PLM00076 A
4-13
Chapter 4
Teamcenter Applications
The Applications functional area contains libraries for specic capabilities and industry solutions.
Classication library
The Classication library currently contains a single service, also called Classication. The following les are used for the Classication library: Java TcSoaClassicationTypes.jar TcSoaClassicationStrong.jar TcSoaClassicationLoose.jar C++ libtcsoaclassicationtypes.dll libtcsoaclassicationstrong.dll C# TcSoaClassicationTypes.dll TcSoaClassicationStrong.dll
4-14
PLM00076 A
Classication service The Classication service exposes operations that correspond to the specic capabilities found in the Teamcenter InClass application. InClass is a Teamcenter application that is used to classify Teamcenter items, typically the parts and assemblies making up manufactured products, into a hierarchy of categories, somewhat like a catalog. It also provides operations which allow the classied items to be searched by attribute, attribute value, classications, and other criteria. Following are the namespaces for the Classication service: Java
com.teamcenter.services.strong.Classification.ClassificationService
C++
Teamcenter::Services::Classification::ClassificationService
C#
Teamcenter.Services.Strong.Classification.ClassificationService
This service contains the following operations: createClassicationObjects deleteClassicationObjects ndClassicationObjects ndClassiedObjects getAttributesForClasses getChildren getClassDescriptions getClassicationObjects getFileIds getKeyLOVs getParents getPartFamilyTemplates search searchByInstanceId searchForClasses updateClassicationObjects
PLM00076 A
4-15
Chapter 4
ProjectManagement library
The ProjectManagement library currently contains a single service: ScheduleManagement. The following les are used for the ProjectManagement library: Java TcSoaProjectManagementTypes.jar TcSoaProjectManagementStrong.jar TcSoaProjectManagementLoose.jar C++ libtcsoaprojectmanagementtypes.dll libtcsoaprojectmanagementstrong.dll C# TcSoaProjectManagementTypes.dll TcSoaProjectManagementStrong.dll ScheduleManagement service The ScheduleManagement service exposes operations that allow for the creation and maintenance of schedules within Teamcenter. These operations are used by the Teamcenter project application but are also available for use in customer applications. Standard operations for the creation and maintenance of project schedules, baselining projects, and adding personnel and calendars are also exposed. Following are the namespaces for the ScheduleManagement service: Java
com.teamcenter.services.strong.ProjectManagement.ScheduleManagementService
C++
Teamcenter::Services::ProjectManagement::ScheduleManagementService
C#
Teamcenter.Services.Strong.ProjectManagement.ScheduleManagementService
This service contains the following operations: addMemberships baselineTasks copySchedules createNewBaselines createSchedule createScheduleDeliverableTemplates createTaskDeliverableTemplates deleteSchedulingObjects
4-16
PLM00076 A
RequirementsManagement library
The Teamcenter RequirementsManagement library currently contains a single service, also called RequirementsManagement. The following les are used for the RequirementsManagement library: Java TcSoaRequirementsManagementTypes.jar TcSoaRequirementsManagementStrong.jar TcSoaRequirementsManagementLoose.jar C++ libtcsoarequirementsmanagementtypes.dll libtcsoarequirementsmanagementstrong.dll C# TcSoaRequirementsManagementTypes.dll TcSoaRequirementsManagementStrong.dll RequirementsManagement service The RequirementsManagement service exposes operations used by the Teamcenter Requirements and Teamcenter Systems Engineering applications. In addition to allowing the creation and maintenance of individual requirements as plain text, the RequirementsManagement service allows rich content (formatted text, diagrams, pictures, and so on) to be imported from common desktop applications. Once imported, this rich content can be exported back out to a desktop application, edited in realtime, and imported back into Teamcenter. Following are the namespaces for the RequirementsManagement service: Java
com.teamcenter.services.strong.RequirementsManagement.RequirementsManagementService
C++
Teamcenter::Services::RequirementsManagement::RequirementsManagementService
C#
Teamcenter.Services.Strong.RequirementsManagement.RequirementsManagementService
This service contains the following operations: createOrUpdate exportToApplication getRichContent importFromApplication setRichContent
PLM00076 A
4-17
Chapter 4
DocumentManagement library
The Teamcenter DocumentManagement library currently contains a single service, the DocumentTemplate service. The following les are used for the DocumentManagement library: Java TcSoaDocumentManagementTypes.jar TcSoaDocumentManagementStrong.jar TcSoaDocumentManagementLoose.jar C++ libtcsoadocumentmanagementtypes.dll libtcsoadocumentmanagementstrong.dll C# TcSoaDocumentManagementTypes.dll TcSoaDocumentManagementStrong.dll DocumentTemplate service The DocumentTemplate service exposes a single operation, getTemplates, which allows for the retrieval of information on the desktop applications that various application le types are associated with. Various criteria can be specied in order to retrieve the subset of templates that are appropriate to the le types the application is interested in at the moment. Following are the namespaces for the DocumentTemplate service: Java
com.teamcenter.services.strong.DocumentManagement.DocumentTemplateService
C++
Teamcenter::Services::DocumentManagement::DocumentTemplateService
C#
Teamcenter.Services.Strong.DocumentManagement.DocumentTemplateService
4-18
PLM00076 A
Teamcenter Distributed Systems

The Distributed Systems functional area covers two major areas of Teamcenter functionality: Teamcenter Global Services and those portions of Global Services that address connectivity and functionality across and between Teamcenter installations. Other portions of Teamcenter Global Services address integration with non-PLM systems and are more appropriately included in the Application Integration functional area. Only the MultiSite library is dened within the Distributed Systems functional area. It has services for Object Directory interaction and IDSM Transfers. There are currently no libraries or services published in the category Teamcenter Distributed Systems.
PLM00076 A
4-19
Chapter 4
Teamcenter Application Integration

Teamcenter applications are generally deployed as one part of a corporate information environment that includes a variety of non-PLM systems and applications. Applications and information managed by Teamcenter must be easily accessible and interoperate smoothly with those other systems and applications.
AI library
The AI library currently contains a single service, also called AI. The application integration capabilities that were exposed through AIWS in earlier versions have been incorporated into the new services API set. The AIWS implementations have been deprecated and should no longer be used for new development. The following les are used for the AI library: Java TcSoaAITypes.jar TcSoaAIStrong.jar TcSoaAILoose.jar C++ libtcsoaaitypes.dll libtcsoaaistrong.dll C# TcSoaAITypes.dll TcSoaAIStrong.dll AI service The AI service exposes operations that are consistent with application integration paradigm and conventions established through AIWS. The new AI operations allow multiple client sessions to be logged on the same Teamcenter server simultaneously. You should ensure that the client discriminator argument in the logon operation of the Session service is used to distinguish the different instances of the client running with the same logon user. A sample services AI client is provided under the soa_client directory on the Teamcenter CD-ROM. Following are the namespaces for the AI service: Java
com.teamcenter.services.strong.AI.AIService
C++
Teamcenter::Services::AI::AIService
C#
Teamcenter.Services.Strong.AI.AIService
4-20
PLM00076 A
This service contains the following operations: commitFiles commitStructureFile createProjects createPublishRequest deleteProjects deleteRequests endExchange generateFullSyncRequest generateStructure getFileReadTickets getFileWriteTickets getNextApprovedRequest getProjects getProjectsInfo getPropertiesOfObjects getRequestsForProject getRequestsInfo getStructureReadTicket getStructureWriteTicket objectsExist processPublishRequest processStructure setExchangeMessage setProjectsInfo startExchange
PLM00076 A
4-21
Chapter 4
CAD library
The CAD library currently exposes two services: DataManagement and StructureManagement. One of the primary applications of Teamcenter in customer operations is as a managed environment for engineering information, whether it is generated through computer-aided design (CAD) tools such as NX or other computer-aided engineering (CAE/CAx) applications. As a result, the Teamcenter CAD services provide a robust set of operations that facilitate the integration of these and similar engineering tools with Teamcenter. The following les are used for the CAD library: Java TcSoaCadTypes.jar TcSoaCadStrong.jar TcSoaCadLoose.jar C++ libtcsoacadtypes.dll libtcsoacadstrong.dll C# TcSoaCadTypes.dll TcSoaCadStrong.dll
4-22
PLM00076 A
DataManagement service The CAD DataManagement service exposes operations that are, in many ways, similar to the core DataManagement services described earlier. The difference is that the CAD operations have been specically designed with the needs of design engineers and design applications which need to be tightly integrated with Teamcenter. Following are the namespaces for the DataManagement service: Java
com.teamcenter.services.strong.Cad.DataManagementService
C++
Teamcenter::Services::Cad::DataManagementService
C#
Teamcenter.Services.Strong.Cad.DataManagementService
This service contains the following operations: createOrUpdateParts createOrUpdateRelations expandFoldersForCAD expandGRMRelations expandPrimaryObjects generateAlternateIds getAllAttrMappings getAttrMappingsForDatasetType getAvailableTypes resolveAttrMappingsForDataset
PLM00076 A
4-23
Chapter 4
StructureManagement service The CAD StructureManagement service exposes operations that allow various kinds of engineering structures (parts, assemblies, and so on) to be easily manipulated within a managed engineering application environment. In this scenario, the structure of the product being designed can be authored in the engineering tool, but stored and managed in Teamcenter. The operations exposed by this service help provide for an exceptional user experience in these situations. Following are the namespaces for the StructureManagement service: Java
com.teamcenter.services.strong.Cad.StructureManagementService
C++
Teamcenter::Services::Cad::StructureManagementService
C#
Teamcenter.Services.Strong.Cad.StructureManagementService
This service contains the following operations: closeBOMWindows createBOMWindows createOrUpdateAbsoluteStructure createOrUpdateRelativeStructure deleteAssemblyArrangements deleteRelativeStructure expandPSAllLevels expandPSOneLevel getRevisionRules getVariantRules
4-24
PLM00076 A
Chapter
Performing common tasks using services
Retrieving basic item information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 Uploading and downloading persistent les . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 Importing and exporting data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
PLM00076 A
Chapter
The basic pattern for invoking Teamcenter services operations is as follows: 1. Populate a set of structures representing the business items that you want to request an operation on. 2. Gather the populated structures into a vector or array as appropriate for the client technology you are using (C++, Java, .NET, and so on). 3. Request a service stub from the Connection object your session is running under. 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 this means listening for updates from the CDM model manager and updating the applications user interface to reect the results of the operation. Most operations take arrays of structures as their input, and return a standard ServiceData object along with one or more operation-specic output structures. Refer to the online services references or the WSDL les and schemas for details on these structures.
PLM00076 A
5-1
Chapter 5
Retrieving basic item information

Basic information about items returned from an operation is contained within the ServiceData object returned from the call. The information in the ServiceData object is controlled through the ObjectPropertyPolicy in place at the time of the operation request. If additional information about the one or more of the returned objects is needed, the DataManagement.getProperties() operation can be called. The input to the DataManagement.getProperties() operation is a vector or array of ModelObjects from the CDM, and a second array or vector containing the names of the Teamcenter properties to retrieve for each ModelObject in the rst array, as in:
getProperties(ModelObject[ ] objects, String[ ] attributes)
The return structure is a standard ServiceData structure that contains the requested ModelObjects with the requested attributes populated into them in addition to the attributes specied in the current ObjectPropertyPolicy. Returning both sets of attributes make it possible for the client application to use the returned ModelObjects directly without worrying about merging the new attributes into the previously returned default set. Note See Policy impact on service performance regarding attribute or property expansion. The same performance impacts discussed there pertain to this operation as well. Attributes used by the client application should be requested on an as-needed basis rather than prefetching a large list of attributes in case the application may need them later. This is, of course, a trade-off between UI responsiveness and performance, and the balance between them often depends on the users expectations when using a specic client application.
5-2
PLM00076 A
Uploading and downloading persistent les

While 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. This bulk data typically consists of various les containing product design geometry from a CAD application, specications, analytical reports, and such. References to these les are stored in Teamcenter in a construct called a dataset that is associated with an item in the Teamcenter database. The actual le content is persisted within Teamcenter File Management System. Uploading a le 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 le. 3. Commit the le into the appropriate dataset using the commitDatasetFiles() operation. An FMS ticket is a token that grants the holder permission to carry out a certain operation, usually an upload or download of one or more les. The ticket generation process interfaces with the Teamcenter access management system to ensure that only authorized users can read, write, or modify bulk data and datasets using FMS. For les 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. Both operations are set-based, which allows multiple tickets to be requested at a single time. On a write, or upload, operation the uploaded les can be attached to datasets and committed to the Teamcenter database using:
commitDatasetFiles(FileManagement.CommitDatasetFileInfo[] commitInput)
For a complete explanation of FMS operations related to persistent les, see the Teamcenter File Management System documentation.
PLM00076 A
5-3
Chapter 5
Importing and exporting data

Often a client application wants to upload a local le and process its content into the Teamcenter database, or extract some information from Teamcenter into a le and download the le for local use. The upload operation is called an import and the download operation is called an export. In either case, the le can be considered just a container which Teamcenter does not have to persist or track once its contents have been transferred into or out of the system. These are referred to as transient les. Similarly to persistent les, transient les are transferred using File Management System (FMS). To import data into Teamcenter using one or more transient les, the client application needs to rst obtain the appropriate write tickets from Teamcenter. The client application can pass the ticket, the local le names, and the name to import the les as, to FMS. Once the les are uploaded, the same tickets can be used to call the Teamcenter operation that retrieves the les from FMS, perform the tasks necessary to parse the le contents and process it into the Teamcenter database. Once the import is complete, FMS by default deletes the transient le, although the client application can request that the le not be deleted by setting a ag 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 les, and completed with:

yourImportProcessor(yourInputStructure[ ] inputs)
Using transient les and FMS to export information from Teamcenter to a local le is conceptually similar to the import use case, but in a slightly different sequence. The rst step in an export operation is to call a Teamcenter service which performs the data extraction, requests the appropriate FMS transient le tickets, writes the les to FMS, and returns the FMS tickets to the calling client. With the returned tickets, the client application can request FMS to download the les. Once the download completes the client application can process the les in whatever manner it chooses. By default, FMS deletes the transient le from the Teamcenter volume it was temporarily written to although there is an option on the getTransientFileTickets() operation to request that the le not be deleted from the Teamcenter volume. For a complete explanation of FMS operations related to transient les, see the Teamcenter File Management System documentation in the Conguration Guide. For more information on specic mechanisms and le formats used in Teamcenter import and export operations, refer to the documentation for the various Teamcenter applications which expose import and export methods.
5-4
PLM00076 A
Index
A Administration library . AI Library . . . . . . . . . . Service . . . . . . . . . . Allocations Library . . . . . . . . . . Service . . . . . . . . . . Application Integration Application Support . . Applications . . . . . . . . C CAD library . . . . . . . CalendarManagement Library . . . . . . . . . Service . . . . . . . . . Calling services . . . . . Classication Library . . . . . . . . . Service . . . . . . . . . Client data model Introduction . . . . . Using . . . . . . . . . . Client libraries . . . . . Common tasks . . . . . Conguring services . Connection object . . . Core library . . . . . . . CredentialManager . . CrfReports Library . . . . . . . . . Service . . . . . . . . . D Data import and export . . . . . . . DataManagement service . . . . . Dening object property policies . Distributed Systems . . . . . . . . . DocumentManagement library . . DocumentTemplate service . . . . Downloading and uploading les . . . . . . . . . . . . . . . . . . 5-4 4-5, 4-23 . . . 3-10 . . . 4-19 . . . 4-18 . . . 4-18 . . . . 5-3 . . . . . . . . . . . . . 4-22 . . . . . . . . . . . . . 4-11 . . . . . . . . . . . . . 4-11 . . . . . . . . . . . . . . 3-3 . . . . . . . . . . . . . 4-14 . . . . . . . . . . . . . 4-15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 3-5 1-4 5-1 1-3 3-2 4-4 3-1 . . . . . . . . . . . . . 4-3 . . . . . . . . . . . . 4-20 . . . . . . . . . . . . 4-20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 4-10 4-20 . 4-9 4-14
E Enabling services . . . . . . . . . Errors Full . . . . . . . . . . . . . . . . . Handling . . . . . . . . . . . . . . Partial . . . . . . . . . . . . . . . Errors and exceptions . . . . . . Establishing a session . . . . . . Exporting and importing data F File upload and download . . . . . . . . . . . 5-3 FileManagement service . . . . . . . . . . . . 4-6 Full service errors . . . . . . . . . . . . . . . . . 3-8 G Getting started with services . . . . . . . . . 1-1 H Handling errors . . . . . . . . . . . . . . . . . . 3-7 I Importing and exporting data . . Inputs . . . . . . . . . . . . . . . . . . Introducing services framework IRM service . . . . . . . . . . . . . . L Libraries, client . . . . . . . . . . . . . . . . . . 1-4 Logging on to Teamcenter . . . . . . . . . . . 3-2 M ManagedRelations service . . . . . . . . . . . 4-7 Message inputs and outputs . . . . . . . . . . 2-3 Message transports . . . . . . . . . . . . . . . . 2-3 O Object property policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 2-3 2-1 4-6 . . . . . . . . 1-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 3-7 3-7 2-5 3-1 5-4
. . . . . . . . . . . . . 4-12 . . . . . . . . . . . . . 4-12
PLM00076 A
Index-1
Index
Dening . . . . . . . . . Introduction . . . . . . Performance . . . . . . Setting . . . . . . . . . . Using . . . . . . . . . . . Organization of services Outputs . . . . . . . . . . . P
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
3-10 . 2-5 3-11 . 3-9 . 3-9 . 4-1 . 2-3
Partial errors . . . . . . . . . . Performance . . . . . . . . . . . Platform . . . . . . . . . . . . . . Policies, object property . . . Prerequisites . . . . . . . . . . ProjectManagement library Q
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. 3-7 3-11 . 4-4 . 3-9 . 1-1 4-16
Query library . . . . . . . . . . . . . . . . . . . 4-13 R Request and response . . . . . . . . RequirementsManagement Library . . . . . . . . . . . . . . . . . Service . . . . . . . . . . . . . . . . . Reservation service . . . . . . . . . . Retrieving basic item information S SavedQuery service . . . . . . . . . . . . . . . 4-13 ScheduleManagement service . . . . . . . 4-16 Service exception errors . . . . . . . . . . . . . 3-8 Services . . . . . . 2-4 . . . . . . . . . . . . . . . . . . . . 4-17 4-17 . 4-7 . 5-2
Benets . . . . . . . . . . . . . . Calling . . . . . . . . . . . . . . . Client libraries . . . . . . . . . Common tasks . . . . . . . . . . Conguring . . . . . . . . . . . . DataManagement . . . . . . . Enabling . . . . . . . . . . . . . . FileManagement . . . . . . . . Framework . . . . . . . . . . . . Getting started . . . . . . . . . IRM . . . . . . . . . . . . . . . . . ManagedRelations . . . . . . . Organization . . . . . . . . . . . Performance . . . . . . . . . . . Prerequisites . . . . . . . . . . . Reservation . . . . . . . . . . . . Session . . . . . . . . . . . . . . . UserManagement . . . . . . . Session service . . . . . . . . . . . Sessions . . . . . . . . . . . . . . . . Setting object property policies SOA . . . . . . . . . . . . . . . . . . . StructureManagement service System Administration library System Denition . . . . . . . . . T
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. 2-2 . 3-3 . 1-4 . 5-1 . 1-3 . 4-5 . 1-2 . 4-6 . 2-1 . 1-1 . 4-6 . 4-7 . 4-1 3-11 . 1-1 . 4-7 . 4-8 . 4-3 . 4-8 . 3-1 . 3-9 . 2-1 4-24 . 4-3 . 4-2
Teamcenter Logging on . . . . . . . . . . . . . . . . . . . . 3-2 Sessions . . . . . . . . . . . . . . . . . . . . . . 3-1 U Uploading and downloading les . . . . . . 5-3 UserManagement service . . . . . . . . . . . . 4-3
Index-2
PLM00076 A

Team Center Services

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Team Center Services

Hochgeladen von

Copyright:

Verfügbare Formate

Teamcenter 2007 Teamcenter Services Guide

Publication Number PLM00076 A

Proprietary and restricted rights notice

Teamcenter Services Guide

Teamcenter Services Guide

Teamcenter Services Guide

Teamcenter Services Guide

Teamcenter Services Guide

Enable Teamcenter Services

Start Teamcenter Services

Teamcenter Services user interface

Teamcenter Services Guide

Conguration required for Teamcenter Services

Connecting a client application to the server

Client libraries in two-tier deployments

WSDL/SOAP in four-tier deployments

Teamcenter Services Guide

Using client libraries

Teamcenter Services Guide

HTTP client (four-tier) XML

libcurl.dll Xerces version 2.6.2:

TcSoaClient.dll System.Xml .NET Framework Version 2.0

icudt32.dll icuin32.dll icuuc32.dll xalan19.dll xerces260.dll

Teamcenter Services Guide

Teamcenter Services Guide

Introducing the Teamcenter Services framework

Teamcenter Services Guide

Introducing the Teamcenter Services framework

Teamcenter Services Guide

Introducing the Teamcenter Services framework

Why Teamcenter Services is important

What you can do with Teamcenter Services

Teamcenter Services advantage for your organization

Teamcenter Services Guide

Introducing the Teamcenter Services framework

Teamcenter Services framework

Available message transports

Common message structures (input and output)

Teamcenter Services Guide

Introducing the Teamcenter Services framework

Request and response interaction patterns

Client data model

Teamcenter Services Guide

Introducing the Teamcenter Services framework

Errors and exceptions

Object property policies

Teamcenter Services Guide

Using Teamcenter Services framework components

3-1 3-1 3-2 3-2 3-2 3-3

Teamcenter Services Guide

Using Teamcenter Services framework components

Establishing a Teamcenter session

Teamcenter Services Guide

Using Teamcenter Services framework components

Teamcenter Services Guide

Using Teamcenter Services framework components

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

Java loosely typed data model:

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

Teamcenter Services Guide

Using Teamcenter Services framework components

C++ strongly typed data model:

.NET strongly typed data model:

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