Star Team SDK Overview Anil PeresdaSilva Principal Software

  • Slides: 99
Download presentation
Star. Team SDK Overview Anil Peres-da-Silva Principal Software Engineer, Star. Team Borland (A Micro

Star. Team SDK Overview Anil Peres-da-Silva Principal Software Engineer, Star. Team Borland (A Micro Focus Company)

Public Packages Java C# – com. starteam Star. Team – com. starteam. viewcomparemerge Star.

Public Packages Java C# – com. starteam Star. Team – com. starteam. viewcomparemerge Star. Team. View. Compare. Merge – com. starteam. events Star. Team. Events – com. starteam. exceptions Star. Team. Exceptions – com. starteam. util Star. Team. Util – com. starteam. xml Star. Team. Xml – com. starteam. diff Star. Team. Diff

Public Packages • Languages & Runtimes – Java (JRE); C# (. NET) The SDK

Public Packages • Languages & Runtimes – Java (JRE); C# (. NET) The SDK is available in Java & C#. The C# version of the SDK is functionally identical to the Java version. As per C# conventions, the namespace name is Star. Team. Names are capitalized & Java get/set accessors become C# properties. e. g. (Java) int s. get. Port() (C#) int s. Port Developed using JDK 1. 2 -, cross-compiled into J#; a small set (+/-20) of language specific java/j# edge classes J# assembly further wrapped in an external C# assembly, generated using meta data reflection • Custom Java applications that do not care about SDK type specific exceptions can ignore the com. starteam. exceptions namespace, and catch java. lang. Runtime. Exception, Exception or Throwable • Similarly, custom C# applications can catch System. Exception • Custom applications that do not care about events can ignore the events namespace. However, MPX aware applications reduce server commands. COM is no longer supported. Application developers can use Star. Team. SDK 11. 0. dll, our last shipping COM release, which is backward compatible to 2005 servers and forward compatible to the 12. 0 server

Public Packages (C# SDK, . NET 4. 0 & VS 2010) • The SDK

Public Packages (C# SDK, . NET 4. 0 & VS 2010) • The SDK C# solution Star. Team. dll depends upon the Star. Team J# assembly (Star. Team. Core. dll) which in turn depends upon the Microsoft. NET 2. 0 native. J# assemblies, vjslib. dll & vjsnativ. dll. They can be downloaded from http: //www. microsoft. com/downloads/en/confirmation. aspx? familyid=f 72 c 74 b 3 -ed 0 e-4 af 8 -ae 63 -2 f 0 e 42501 be 1 (32) http: //www. microsoft. com/downloads/en/details. aspx? Family. ID=42 C 46554 -5313 -4348 -BF 81 -9 BB 133518945 (64) • The. NET 4. 0 runtime does not load. NET 2. 0 assemblies. Application developers need to assume this responsibility themselves. • There a few issues you may run into when using VS 2010. • If you are developing a Windows Forms Application, the default Project Setting for the Target Framework is '. NET Framework 4 Client Profile'. Attempting to compile your code with this setting returns the following warning • Warning The referenced assembly “…" could not be resolved because it has a dependency on "System. Web, …" which is not in the currently targeted framework ". NETFramework, Version=v 4. 0, Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project. • & error Error The type or namespace name 'Star. Team' could not be found (are you missing a using directive or an assembly reference? ) • To address this, you must change the Target Framework setting to '. NET Framework 4' and rebuild

Public Packages (C# SDK, . NET 4. 0 & VS 2010) • • Your

Public Packages (C# SDK, . NET 4. 0 & VS 2010) • • Your application code (whether Windows Forms or ASP. NET) must load the vjsnativ & vjslib assembly. dll's. 1) include the assembly System. Runtime. Interop. Services; 2) explicitly declare & load the assemblies (keep them loaded for the life of your application) [Dll. Import("kernel 32. dll")] private extern static Int. Ptr Load. Library(string file. Name); [Dll. Import("kernel 32. dll")] private extern static bool Free. Library(Int. Ptr lib); string folder = Path. Combine(Environment. Get. Folder. Path(Environment. Special. Folder. System), @". . Microsoft. NETFrameworkv 2. 0. 50727"); folder = Path. Get. Full. Path(folder); Int. Ptr ptr 1 = Load. Library(Path. Combine(folder, “vjslib. dll"); Int. Ptr ptr 2 = Load. Library(Path. Combine(folder, “vjsnativ. dll"); then instantiate & use the Star. Team objects Server s = new Server("localhost", 49201); s. Log. On("Administrator", "Administrator"); … You may choose to free the loaded libraries when your application is shutting down Free. Library(ptr 1); Free. Library(ptr 2);

Object Model Grouped classes with common functionality; Reduced ‘clutter’ in com. starteam Java implementation

Object Model Grouped classes with common functionality; Reduced ‘clutter’ in com. starteam Java implementation compiled using JDK 1. 5 but constrained to JDK 1. 2 - api’s (for J#. NET); client application developers have no such constraint Encapsulation Techniques: Tight Binding & Close Coupling example – Typed Resource is the base of all Star. Team Artifacts; Type is the base of all Star. Team types – Every Typed Resource has a unique Type – Items & Projects are both Typed. Resources; An Item. Type is not a Project. Type – Alternatives development approaches : - • Item. Type. java, Project. Type. java (weak coupling between Item & it’s Type) – the separate classes approach • Item. Type, Project. Type (strong coupling between Item & its Type) – the public static class approach Consistency & Strong Typing. The ‘objects everywhere’ approach

Object Model • • Consistency & Strong Typing Objects v/s Strings – Names are

Object Model • • Consistency & Strong Typing Objects v/s Strings – Names are user friendly properties, not representations of SDK Objects. – Example – • Folder. count. Items(String type. Name, int depth) (com. starbase. starteam) • Folder. count. Items(Type t, int depth) (com. starteam) Objects v/s Integers – Integer IDs are internal keys, not representations of SDK Objects. – Example – ACLEntry. add. Permission(int permission. ID) (com. starbase. starteam) – ACE. add. Permission(Permission p) (com. starteam)

Object Model • • Objects v/s Static Integer Constants – Example – public static

Object Model • • Objects v/s Static Integer Constants – Example – public static final int Label. NEXT_BULD_ID; – public static final Label. NEXT_BUILD; Objects v/s Grouped Static Integer Constants – Example – public class Product. Codes { » public static final int STANDARD; » public static final int ENTERPRISE; – public static final class Server. Product. Code { » public static final Product. Code STANDARD; » public static final Product. Code ENTERPRISE; (com. starbase. starteam) (com. starteam)

Object Model – Typed Resource is the base class for all Star. Team Artifacts

Object Model – Typed Resource is the base class for all Star. Team Artifacts – Type is the base class for all Star. Team types – Each Typed Resource has a unique Type; each Type has a unique Property Collection which derives from the underlying type’s property collection. – SDK Objects have properties, methods, events – Properties may be primitives (String, int, boolean, double), SDK Objects, arrays of primitives or arrays of SDK Objects – Properties may be specialized SDK Collections (themselves SDK Objects) – Method arguments and return types may be primitives, SDK Objects, arrays or SDK Collections – Event arguments may be primitives, SDK Objects, arrays or SDK Collections – Custom component application developers may choose to sub-class Item or Tree Item directly – Types may be customized; custom properties can be added to stock or custom components – The new SDK Object model closely mirrors the Server Object Model.

Object Model (Artifact Hierarchy)

Object Model (Artifact Hierarchy)

Object Model (Type Hierarchy)

Object Model (Type Hierarchy)

Object Model (Property Hierarchy)

Object Model (Property Hierarchy)

Object Model (Property. Collection Hierarchy)

Object Model (Property. Collection Hierarchy)

Server, MPX & Cache. Agent import com. starteam. *; An application must connect to

Server, MPX & Cache. Agent import com. starteam. *; An application must connect to the Star. Team Server before it can do anything else Server s = new Server(“localhost”, 49201); User u = s. logon(“Administrator”, “Administrator”); // is equivalent to s. get. Logged. In. User() if (s. is. MPXAvailable()) s. enable. MPX(); // MPX aware applications minimize server commands. Updates are pushed to the client Cache. Agent ca = s. locate. Cache. Agent(“localhost”, 5101); // OR ca = s. auto. Locate. Cache. Agent(); s. disconnect(); // automatically disables MPX, if enabled @see s. disable. MPX(); Once a Cache Agent is located, the SDK automatically fetches File Content from the Cache Agent if available. see {Root/Remote}Cache. Agent. Config. xml in your Cache Agent install folder Commands issued on a server instance are throttled through a single socket. (But multiple server instances can be used to form a connection pool, which is the basis for the web framework)

Server, MPX & Cache. Agent • • • MPX is a framework for publish/subscribe

Server, MPX & Cache. Agent • • • MPX is a framework for publish/subscribe messaging. The Star. Team. MPX Server uses an advanced caching and communication technology that both improves the performance of Star. Team clients and extends the scalability of the Star. Team Server. Star. Team. MPX benefits Star. Team SDK applications in two important ways: Instant Refresh. An MPX-enabled SDK application can refresh changes from the server with very little overhead. For applications that perform frequent refresh operations, the resulting performance benefits are significant. Event-Handling. An MPX-enabled SDK application can subscribe to specific server events (for example an Item is added, modified or deleted), and provide event-handlers that are invoked when those events occur. When MPX is enabled, the SDK establishes a connection to the Star. Team. MPX message broker, and subscribes to events for this server. Even though MPX is enabled through a specific Server object, it is really the communication layer between the SDK and the Star. Team repository that is MPX-enabled. Thus, enabling MPX on a specific Server object also enables MPX for other Server objects in the same runtime that share the same address and port.

Types & Properties // Type. Collection extends Star. Team. Collection implements java. util. Collection

Types & Properties // Type. Collection extends Star. Team. Collection implements java. util. Collection // Star. Team. Collection is a type safe abstract base class for all SDK collections Type. Collection tc = (Server) s. get. Types(); Type[] tt = (Type[])tc. to. Array(new Type[tc. size()]); for (int i = 0; i < tt. length; i++) { Type t = tt[i]; // && access the properties for a give Type t Property. Collection pc = t. get. Properties(); Property[] pp = (Property[])pc. to. Array(new Property[pc. size()]); } // OR find a Type by it’s name, useful for custom component developers. Custom Components are new to 12. 0 Story. Type t = (Story. Type)tc. find(“Story”); //The 12. 0 Server supports creation of custom types (components) via the SDK. @see Server. create. Type(String xml. Definition);

Types & Properties Type. new. XXXProperty(…) api’s are used to create/add Custom Properties to

Types & Properties Type. new. XXXProperty(…) api’s are used to create/add Custom Properties to any Item derived Type The Star. Team Server supports creation of all Property Types except Link and Binary Properties The 12. 0 Server Release introduces three new property types; Content. Property, Map. Property & Multi-Select Enumerations. It also supports the creation of custom Object and Object. Array properties - which store User(s) or Group(s) values; and custom Date (without a time component) properties Content Property types store arbitrary binary, rich text, html, . pdf etc. content in the Star. Team & Cache Agent Vaults. Just like File Content, Content Property Values are retrieved either from the server or the closest cache agent. Map Property types serialize Maps (Hash Sets) of arbitrary key-value pairs to the Star. Team database Maps can be queried using new Query Relations (CONTAINS_KEY, CONTAINS_VALUE & KEY_CONTAINS_VALUE) The Map Property supports the native value types String, Integer, Long, Boolean, Double, Float and Date. In addition, it supports the SDK types Date, Date. Time, MD 5, GUID, Dot. Notation, Time. Span and Content Multi-Select Enumerations allow more than 1 Enumerated Value to be selected, stored & retrieved.

Types & Properties Property p = t. new. Double. Property(“Cost. Price”); Create custom properties

Types & Properties Property p = t. new. Double. Property(“Cost. Price”); Create custom properties for a given Type t p. update(); // issue the server command, and creates the property on the server p = t. get. Properties(). find(“Usr_Cost. Price”); // the server automatically prefixes Usr_ to the name Type & Property creation can be slow, and can adversely affect connected users Types have associated metadata (properties) t. is. Branchable(); // Tree Item types are NOT branchable t. is. Component. Type(); // Files, Folders, Change. Requests, Custom Components are all component types The 12. 0 server supports modifying the Type display name & Translations for all Item derived Types. Properties have associated metadata p. is. Client. Calculated(); // Client side property whose value is calculated on the fly p. is. Server. Calculated(); // Server side property whose value is calculated on the server; @see p. is. Stored() p. is. Revision. Independent(); // Server property whose value is fixed across all revisions

Projects, Views, Folders & Items Project[] pp = s. get. Projects(); Project p =

Projects, Views, Folders & Items Project[] pp = s. get. Projects(); Project p = s. find. Project(“Star. Draw”); // A server manages multiple projects View[] vv = p. get. View(); View v = p. find. View(“Release 1. 0 Maintenance”); // a project can contain multiple views // The root or default view of a project has a special accessor p. get. Default. View() View[] vv = v. get. Derived. Views(); // Views can be arranged in trees Folder f = v. get. Root. Folder(); // every view has a default root folder created by the server Folder[] kids = f. get. Sub. Folders(); // Folders can be arranged in trees Projects, View and Folders form a containment hierarchy. Items are contained in Folders, and can be accessed from the parent folder or the view. Item. Type cstm. Typ = s. get. Types(). find(“Visualization”); // Item. Type extends com. starteam. Type v. find. Item(cstm. Typ, -1); // load all item id’s of a given type in a single server command View. Member. Collection vmc = f. get. Items(cstm. Typ); // gather the entire set of items in a specific folder View. Member. Collection vmc = f. get. View(). get. View. Members(cstm. Typ); // gather the entire set of items in the view Item itm = v. find. Item(cstm. Typ, 145); // find a specific item by ID (IDs are unique server wide)

Items & View Members • View. Members are artifacts that reside ‘in a view’,

Items & View Members • View. Members are artifacts that reside ‘in a view’, (technically, in the default root folder of the view) • Non-Item View Members do not have a parent folder property • Change Packages & Traces are view members, not items. They do not reside in parent folders. • Stock & Custom Components are Items are View Members that reside in a parent folder in the view. By definition, component instances are contained in their parent folder and contained in their view. • Tree Items are Items that have parent child relationships. An entire tree must reside in a single folder – but different trees may reside in the same or different folders. • By default (i. e. out of the box) Custom Component Types are surfaced as Item or Tree. Item instances. Client application developers may choose to extend the SDK object model in their own namespace and have their {Tree}Item derived classes become first class SDK citizens!

Items & View. Members Every view member has a type, which in turn has

Items & View. Members Every view member has a type, which in turn has a collection of properties. At runtime, the values of the properties of view member instances can be retrieved or changed generically Object o = itm. get. Value(Property); // return the value of this property for this item instance Object itm. set. Value(Property, Object); // set the value of this property, return the previous value itm. update(); // persists this item in its new state on the server. The in memory item is no longer dirty Stock component types also have type safe accessors that supplement the generic get/set Value api’s When an item is updated more than once, the history of all changes can be queried View. Member. Collection history = item. get. History(); // the first entry in the collection is the tip Item instances may be shared across folders and views. A share tree represents the class of items with the same root Item shr = itm. share. To(f); // share this item to a different folder, return the newly created share The specified folder may be in the same view or a different view of this project, Items cannot be shared across servers. Share[] ss = itm. get. All. Shares(); // returns the share tree of this item, which may be walked recursively

Items & View. Members for all the stock item types, each generic get/set accessor

Items & View. Members for all the stock item types, each generic get/set accessor typically has equivalent type specific accessors boolean b = ((Boolean)itm. get. Value(pc. find(View. Member. Type. Is. Read. Only. Property. NAME))). boolean. Value(); // is equivalent to boolean b = itm. is. Read. Only(); // a read-write property example Requirement. Type rqmt. Typ = s. get. Types(). REQUIREMENT; Requirement r = (Requirement)v. find. Item(rqmt. Typ, 12345); Requirement. Type. Property. Collection pc = r. get. Properties(); int ambiguities = r. get. Ambiguities. Count(); // is equivalent to… ambiguities = ((Integer)r. get. Value(pc. AMBIGUITIES_COUNT)). int. Value(); r. set. Ambiguities. Count(ambiguities); // is equivalent to… r. set. Value(pc. AMBIGUITIES_COUNT, new Integer(ambiguities)); pc. AMBIGUITIES_COUNT is equivalent to pc. find(Requirement. Type. Ambiguities. Count. Property. NAME) There is typically more than one way to do the same thing through the SDK. Pick the model that suits you best.

Folders & Items Folders are Items. Folders are also containers for items. A folder

Folders & Items Folders are Items. Folders are also containers for items. A folder can have at most one parent folder, bur multiple child folders. An item can have at most one parent folder. Related Tree Items, i. e. parents, children, descendants, can be contained in at most one folder. f. populate(cstm. Typ, pc, depth); // ensures that the set of items specified by this type and depth are populated with the set of properties specified in the property collection. The property values need not be up to date over time. f. refresh. Items(cstm. Typ, pc, depth); // ensures that the set of items specified by this type and depth are populated with the set of properties specified in the property collection and are kept up to date. If MPX is enabled, refresh will not Issue a server command. Without MPX, a server command to re-fetch properties is triggered, whether or not they are up to date. boolean f. is. Refresh. Items. Required(cstm. Typ, pc, depth); // tests whether property values are up to date. MPX enabled applications will only return true if an in-memory refresh is required. This method always returns true for applications that are not MPX enabled. boolean f. is. Populated(cstm. Typ) will return true iff all the items of this type in this folder have all properties populated. .

Collections • Public abstract base class Star. Team. Collection – In Java, implements java.

Collections • Public abstract base class Star. Team. Collection – In Java, implements java. util. Collection – In C#, implements System. Collections. IList – Assignable member type safety enforced • Collections returned through SDK Interfaces are immutable & read-only, i. e. members cannot be added or removed, e. g. • Server. get. Types() a read-only collection of server supported types. • Type. get. Properties() a read-only collection of type specific properties • Newly created collections are write-able by default • new Property. Collection(), new View. Member. Collection() return empty, mutable collections • Application developers can ‘roll their own’ collections by sub-classing Star. Team. Collection

Collections

Collections

View. Member. Collection A managed collection of View. Member instances spanning project(s) or view(s)

View. Member. Collection A managed collection of View. Member instances spanning project(s) or view(s) across a server provides several methods with bulk implementations, minimizing network round trips i. e. one command issued (per type, per view) for the entire set of View. Members in the collection View. Member. Collection vmc = new View. Member. Collection(); // collect items as necessary from different projects or views or folders across the server vmc. add. All(s. find. Project(“Star. Draw”). get. Default. View(). get. Root. Folder(). get. Items(cstm. Typ)); vmc. add. All(s. find. Project(“Star. Draw”). find. View(“Release 1. 0 Maintenance”). get. Root. Folder(). get. Items(cstm. Typ)); Property. Collection pc = new Property. Collection(); pc. add(cstm. Typ. get. Properties(). find(View. Member. Type. Item. Deleted. By. Property. NAME); // a stock property pc. add(cstm. Typ. get. Properties(). find(“Usr_Cost. Price”); // a custom property vmc. get. Cache(). populate(pc); // populate all items in this collection with the property values specified View. Member. Collection hstry = vmc. get. From. History(new Date. Time(2009, 00, 01)); // return all historical revisions of these view members as of the specified date (this may be a smaller set, since some of these items may not have existed on that day and at that time)

View. Member. Collection History. Container hc = vmc. get. History(); // return all historical

View. Member. Collection History. Container hc = vmc. get. History(); // return all historical revisions of all the View. Members in the collection // to access the history of an individual view member, query the History. Container for that one View. Member. Collection hstry = hc. get. History(vmc. get. At(0)); // the history of the zero-th View. Member // History is the set of all revisions of an item from the tip (0 th) to the oldest (nth) instance vmc. lock. Exclusive(true); // exclusively lock all the members of this collection (break another users lock), or unlock() Behavior. Container bc = vmc. get. View. Member. Behavior(); // return the behavior of all view members in this collection; (Behavior describes the branching or floating characteristic) // to access the behavior of an individual view member, query the Behavior. Container for that one View. Member. Behavior vmb = bc. get. Behavior(vmc. get. At(0)); // Similarly, create and use a Behavior. Container to change the behavior of a set of View. Members in bulk; // using the fewest set of server commands. Once items are in the view member collection, they can be searched for by itemid or ‘name’, the name being the value of the Primary Descriptor property. @see vmc. find(int)

Type. Collection A managed collection of all Types surfaced by the Server. This includes

Type. Collection A managed collection of all Types surfaced by the Server. This includes types for custom components created by application developers, at server startup or on the fly. The server wide type collection is obtained by querying the server object after login. @see Type. Collection Server. get. Types(); Types may be iterated over or found by id (int) or name (string); i. e. Server s = new Server(“host”, port); … Type. Collection tc = s. get. Types(); tc. PROJECT is equivalent to tc. find(Project. Type. NAME) is equivalent to tc. find(tc. PROJECT. get. ID()); Each system defined type is declared as a public property on the Type. Collection. for example, Type. Collection. PROJECT, Type. Collection. FILE Custom types (created at runtime) may be found by name (preferably, since the name is assigned by the component developer) or integer id (assigned by the server when the type is created).

Property. Collection A managed collection of all Properties surfaced by the Server for a

Property. Collection A managed collection of all Properties surfaced by the Server for a given Type. This includes types for custom components created by application developers, at server startup or on the fly. A property collection is obtained as a query on a Type. @see Property. Collection Type. get. Properties(); Properties may be iterated over or found by id (int) or name (string); i. e. @see Property. Collection. find(int), Property. Collection. find(String) Each SDK Type defines a Property. Collection that extends the base class Property. Collection, and provides accessors for individual properties injected by that type. for example, File. Type. Property. Collection. HIVE is equivalent to File. Type. Property. Collection. find(File. Type. Hive. Property. NAME) Custom properties can be found by name (the server appends Usr_ to the name of custom properties created through the SDK) or by ID (a unique integer value assigned by the server when the property is created)

Populating Item Properties If the property value of an item instance is not available

Populating Item Properties If the property value of an item instance is not available in memory, querying for that value issues a server call Well behaved applications pre-populate the properties they care about, on the items they care about, early. The SDK can populate a set of requested properties for a given set of items in a single ‘bulk’ server command Property. Collection pc = new Property. Collection(); pc. add(cstm. Typ. get. Properties(). find(View. Member. Type. Item. Deleted. By. Property. NAME); // a stock property pc. add(cstm. Typ. get. Properties(). find(“Usr_Cost. Price”); // a custom property f. populate(cstm. Typ, pc, /*depth=*/ 0); // populate all items // depth = 0 in this folder only // depth = 1 this folder & its subfolders, etc; depth = -1 recurse entire folder tree from this folder down View. Member. Collection vmc = f. get. Items(cstm. Typ); for (int i = 0; i < vmc. get. Size(); i++) { View. Member mbr = (View. Member)vmc. get. At(i); User u = mbr. get. Deleted. By(); // this property value is now in memory double dbl = ((Double)mbr. get. Value(cstm. Typ. get. Properties(). find(“Usr_Cost. Price”))). double. Value(); // and so is this boolean b = mbr. is. Read. Only(); // but this one is NOT & triggers a separate cross network server command per item! Poor application performance, increased network traffic, decreased server scalability } // To conserve memory, discard cached data when done. @see View. Member. get. Cache. Service(). discard();

Net. Monitor & Server. Command. Listener // an interface through which server command notifications

Net. Monitor & Server. Command. Listener // an interface through which server command notifications are fired // useful for debugging, identifying unnecessary server commands and optimizing client-server traffic in SDK applications class Srvr. Cmd. Lstnr implements Server. Command. Listener { public void on. Start(Server. Command. Event e) { System. out. println(e. is. Property. Fetch. Trigered()); System. out. println(e. get. Command. Name()); } } Srvr. Cmd. Lstnr scl = new Srvr. Cmd. Lstnr(); // // when writing & testing code, put this in a DEBUG section Net. Monitor. add. Server. Command. Listener(scl); // the listener gets notified when the command starts and ends … boolean b = mbr. is. Read. Only(); // from the earlier example, is. Property. Fetch. Triggered() will print true in the listener … Net. Monitor. remove. Server. Command. Listener(scl); // always remove the listener when done

Users & Groups Given a logged in Server Object s, load Users & Groups

Users & Groups Given a logged in Server Object s, load Users & Groups from the server. Full user & group information is not retrieved, since the user logging in may not have administrative privileges to access full account information of other users. A logged in user with full administrative privileges can retrieve fully loaded users & groups through Server. Administration. A user may belong to multiple (un)related groups User[] uu = s. get. Active. Users(); // s. get. Users() includes deleted users Group[] gg = s. get. Active. Groups(); // s. get. Groups() includes deleted groups User u = s. get. Logged. In. User(); // the user who logged into this session for (int i = 0; i < gg. length; i++) { Group[] ss = gg[i]. get. Sub. Groups(); // subgroups of this group; a group may have only one parent User[] mm = gg[i]. fetch. Members(/*descendants=*/ false); // the set of users who are members of this group // true to retrieve the entire set of Users who are members of this group and all its descendants } Groups are MPX enabled from 12. 0+ servers; @see refresh. Users(); refresh. Groups(); User Group membership (relationship) queries are bulkified from 12. 0+ servers

Filters A Filter is a user definable ordered & grouped collection of Properties Type

Filters A Filter is a user definable ordered & grouped collection of Properties Type cstm. Typ = s. get. Types(). find(“Visualization”); Filter[] ff = cstm. Type. get. Filters(); // Load Filters for a specific Type Filter l = cstm. Type. get. Filter(“<Must Fix CRs>”); // find a filter by Name Filter l = cstm. Typ. get. Filter(12345): // find a filter by ID ( a server wide unique integer) cstm. Typ. refresh. Filters. And. Queries(); // ensures an up to date list of Filters and Queries is available. for (int i = 0; i < ff. length; i++) { Filter l = ff[i]; Filter. Column[] cc = l. get. Columns(); // the set of properties comprising this filter, in columnar order Filter. Grouping[] gg = l. get. Groupings(); // the subset of properties used for sorting or grouping }

Queries A Query is a user definable condition that may be applied to select

Queries A Query is a user definable condition that may be applied to select a subset of Items for a given Type A query is constructed from a Query. Node, which recursively comprises Query. Nodes, Query. Parts & Relations. Typically the Cross Platform Client (CPC) is best used to construct Queries Type cstm. Typ = s. get. Types(). find(“Visualization”); Query[] qq = cstm. Typ. get. Queries(); // Load Queries for a specific Type Query q = cstm. Type. get. Query(“By Status And Responsibility”); // // find a query by Name Query q = cstm. Typ. get. Query(12345): // find a filter or a query by ID Property. Collection pc = q. get. Properties(); // the set of properties described by this query’ Query. Nodes & Query. Parts Item itm = v. find. Item(cstm. Type, /*ID=*/ 123456); boolean b = q. evaluate(null, itm); // evaluate the query; returns true if the query includes (selects) this item Query. Node qn = q. get. Query. Node(); Query. Node[] nn = qn. get. Query. Nodes(); // the set of Query. Nodes that belong to ‘this’ Query Node Query. Part[] pp = qn. get. Query. Parts(); // the set of Query. Parts that belong to ‘this Query. Node

View. Member. Revision’s are created when one modifies the view level properties of the

View. Member. Revision’s are created when one modifies the view level properties of the item. These property modifications include 1) Changing the Item Branching Behavior 2) Changing the Item Configuration 3) Branching the Item 4) Moving the Item To access a View. Member. Revision array, use the api View. Member: : get. View. Member. Revisions(); The api returns revisions ordered from most recent (first) to least recent (last) Walk this array to discover when an item has moved. (a common use case). The Parent. Folder. Item. ID property of a View. Member. Revision will have changed between two back to back revisions, signifying a move. If the View. ID property has also changed, then the move is a cross view move. Walk the array to discover other property modifications as well, even though these may be less common use cases.

Shares are created when you share an item across folders (The folder may belong

Shares are created when you share an item across folders (The folder may belong to the. same or a different view) @see Item. share. To(Folder), Item. reverse. Share. To(Folder), Trace. share. To(View) A reverse share is prefered when the direction of the share is opposite to the direction of the share tree, i. e. when ‘sharing’ an item from a child view to its parent view, using a reverse share ensures that the resultant share tree follows the direction of the view hierarchy. @see Share[] View. Member. get. All. Shares() to query the share tree of an item or view member @see Share View. Member. get. Share() to query the single share that represents ‘this’ item or view member in its tree. A Share has a Parent Share (may be null for the root share) and a set of child shares (which may be empty) View. Member’s with the same root object ID are all members of the same share tree. They may reside in different folders in the same or different views. Shares may have different object ids, which represent their depth in the share tree. Items whose ‘parent share’ have the same object id are all at the same level in the share tree. Note that Change. Packages cannot be shared across views. However, they can be replayed, which results in the creation of a new change package in the target view, and shares of the contained items that represent the differences.

Labels A named configuration of View. Member instances. Labels may be applied to an

Labels A named configuration of View. Member instances. Labels may be applied to an entire view (View Labels) or to individual Item revisions in a View (Revision Labels) View v = s. find. Project(“Star. Draw”). get. Default. View(); Label l = v. create. View. Label(“label name”, “description”, Date. Time. CURRENT_SERVER_TIME, /*build. Label=*/ true, /*frozen=*/ false); // a build label set to the current server time Label l = v. create. Revision. Label(“label name”, “description”, /*frozen=*/ false); // a revision label View. Member. Collection vmc = new View. Member. Collection(); vmc. add. All(v. get. Root. Folder(). get. Items(cstm. Typ); l. attach. To(vmc); // attach all the members of the collection to this label; (these members are from the tip configuration) vmc = vmc. get. From. History(new Date. Time(2009, 0, 1)); // get all historical revisions on 1/1/2009 l. attach. To(vmc); // attach historical revisions to the label

Labels l. detach. From(vmc); // detach the label from the members of the collection

Labels l. detach. From(vmc); // detach the label from the members of the collection View. Member. Collection vmc. Ex = l. get. Labeled. Items(vmc); // returns the (sub)set of items in this collection which have label l attached to them There is no direct way to query a label for the set of items (at the specific revisions) which are attached to it. Currently, an application needs to fetch all the id’s of any items it is interested in, @see View. find. Item(Type, -1) find the subset which has some revision attached to the label @see Label. get. Labeled. Items(View. Member. Collection) and then query for the actual revisions @see View. Member. Collection. get. From. History(Label) which is a bulk query from Star. Team 12. 0 Alternatively, an application may open a view (using a label based configuration) find the items, process them, and close the view @see View(View. Configuration) Note that opening a view is a fairly expensive operation on the Star. Team server

Traces A strongly typed bi-directional relationship between two artifacts. Traces can be created across

Traces A strongly typed bi-directional relationship between two artifacts. Traces can be created across views, projects and even servers. Traces may be stored in any view on the source or target server, or in a view on an entirely different Server. Traces may be created between Star. Team artifacts and non Star. Team artifacts (e. g. an HTTP URL) Traces are View. Members, and consequently, may be branched, versioned or shared. However, unlike Items, Traces are not stored in Folders. Traces are created by VCM, and by Checkin Manager, between the Change. Package and any Process Item(s) in Scope. These Traces are created in the same view as the Change. Package. Unlike links, traces have history which may be queried. A historical revision may be pinned to different source or target revisions or may float. Trace t = new Trace(view); t. set. Source(view. find. Item(cstm. Typ, 12345)); t. set. Target(view. find. Item(rqrmnt. Typ, 67890)); // or alternatively t. set. Target(Link. Value. for. URL(“http: //www. cnn. com”)); t. unpin. Target(); // the Trace floats at the tip revision of the target t. update(); Trace. Collection trc = view. get. Traces(); // query all the traces in a view Trace. Collection trc = trc. get. Traces(view. find. Item(cstm. Typ, 12345)); // find the subset of traces that reference this item Traces subsume Star. Team links.

Change Packages • A set of changes comprising a single logical Change • Committed

Change Packages • A set of changes comprising a single logical Change • Committed in a single atomic transaction • Created by a VCM session (Promote, Rebase, replicate) in the target view – For each change, record the source & the target revisions at the transaction commit time • Created by Checkin Manager – Record newly added files & folders, changed, deleted or moved files. – Source & target revision are from the same view, the change records the pre commit and the commit(ted) revisions • Change. Package APIs query for Change. Collection, Source View, Target View and Transaction properties. All these properties are read-only. • Change. Pacakges may be replayed from one view to another within a project. • Change. Packages provide a valuable audit trail of file checkin changes & deltas

Attachments are named Content values stored by the Star. Team Server per artifact Each

Attachments are named Content values stored by the Star. Team Server per artifact Each artifact instance has an implicit associated Attachment ‘Property’. Files & Folders do not subscribe to the Attachment Service. All other View. Member & Custom Component Types do The server can store up to 64 attachments per artifact instance. The 11. 0 server stores attachments in a private folder managed by the server. The 12. 0 server stores attachments in the Star. Team vault, keyed by MD 5, along with File & Content Values. (eliminates duplication, orphans can be pruned, fits existing vault back up startegies, etc) The SDK exposes Attachments as a Content[]. Each Content object has a unique integer ID, a Name & an MD 5. Content[] View. Member. get. Attachments(). The Attachment Content (data payload) itself is fetched by calling the to. Bytes(), to. File(), to. Stream() or to. String() api’s on the Content object from the array. View. Member. set. Attachments(Content[]) saves the Attachments to the server, and updates the internal state with the new Attachment Names, IDs and MD 5 s.

Impersonation Enable User Impersonation via a single connected Server Instance (useful for developing web

Impersonation Enable User Impersonation via a single connected Server Instance (useful for developing web applications, Import Export algorithms, etc. ) User admin = s. get. Logged. In. User(); // the original logged in User Impersonate. User iu = new Impersonate. User(s); iu. enable. Impersonation(); // once enabled, impersonation cannot be disabled User u = s. logon(“another. User”, “password”); // The Star. Team server does NOT support logging off a User iu. switch. Context(u); // subsequent commands are executed in this user context iu. switch. Context(admin); // until you switch back to a different user, OR alternatively, use iu. set. Command. User(other); // unlike switch. Context(), the other user need NOT have been logged in via this server instance; but subsequent commands are executed in his/her context at the appropriate privilege level com. starteam. util. Date. Time dt = new Date. Time(2010, /*January*/ 0, 1); iu. set. Command. Time(dt); // overrides current server time, sets the ‘execution time’ for all subsequent commands iu. set. Command. Time(Date. Time. CURRENT_SERVER_TIME); // reset to use server time from here on out

Access Rights & Permissions Star. Team supports Server wide, view specific, container (project, view

Access Rights & Permissions Star. Team supports Server wide, view specific, container (project, view & folder) level & individual item permissions. Supported permissions are described in Permission & aggregated in Permission. Collection (a Star. Team. Collection) All Star. Team SDK components (including containers like view & folder) implement the ISecurable interface. Folders, Projects & Views implement the ISecurable. Container interface Securable Object instances may be assigned a collection of Access Control Entries (ACE’s) Each ACE is a collection of Permissions that may be assigned to a Securable in the context of a User or Group. A common misconception is that denying access to a user (or group) is sufficient – that everyone else (or the Administrators Group) automatically has access to the object. This is the source of most pitfalls when using the security model. An ACE must be explicitly granted access to those who require it and denied access to those who do not. Securable Object instances may be queried for permissions granted to the currently logged in user. Similarly, Securable Containers may be queried for permissions granted or denied to the currently logged in user for all objects of a given type. Against 12. 0+ servers, get. Rights will not issue a server command if MPX is enabled.

Access. Rights. Manager A dynamic managed collection of access rights for a set of

Access. Rights. Manager A dynamic managed collection of access rights for a set of Securable Objects and Containers across a server Access. Rights. Manager arm = new Access. Rights. Manager(s); // create an Access Rights Manager for a given server View. Member[] vmb = view. get. Root. Folder(). get. Items(cstm. Type, 0); arm. populate(ISecurable[] {vmb[0], vmb[1], …}); // load and manage access rights for the specified collection of securable object instances; all access rights queries are bulkified from 12. 0+ servers arm. populate(new ISecurable. Container[] {view. get. Root. Folder()}, cstm. Typ); // load and manage the access rights for instances of the custom Type contained within the root folder of the view ACE[] aces = arm. get. Rights(vmb[0]); // the access control list for this securable instance Permission. Collection pc = new Permission. Collection(); pc. add(Permission. GENERIC_SEE_OBJECT); pc. add(Permission. GENERIC_MODIFY_OBJECT); boolean b = arm. is. Access. Granted(s. get. Logged. In. User(), pc, vmb[0]); // does the logged in user have the right to see or modify the specified securable object instance? arm. refresh(); // discard & re-populate cached Access Rights Information for all managed Objects & Containers. // Optimized NOT to issue server commands against 12. 0+ servers with MPX enabled

Folder. List. Manager & View. Member. List. Manager A managed dynamic collection of Folders

Folder. List. Manager & View. Member. List. Manager A managed dynamic collection of Folders created by including &/or excluding selected folders &/or their sub-folders Folder. List. Manager flm = new Folder. List. Manager(view); // create a Manager in a specific view context flm. include. Folders(view. get. Root. Folder(), Filter. Context. SERVER, /*depth=*/ -1); // exclude an entire branch of the tree using flm. exclude. Folders(…) View. Member. Collection ff = flm. get. Folders(); // the flattened set of Folders being managed by this collection flm. refresh(); // ensure that the list is up to date. If MPX is enabled, refresh() may not issue any server commands A managed dynamic collection of Items of type cstm. Typ, contained in the folders specified by the Folder. List. Manager View. Member. List. Manager vmlm = new View. Member. List. Manager(cstm. Typ, flm); Once the collection is built up, it can be queried in different ways View. Member. Collection vmc = vmlm. get. View. Members(); // return all the members of this collection vmc = vmlm. select. By(cstm. Typ. get. Query(“By Status And Responsibility”)); // return those members of this collection that satisfy the constraints imposed by the selected query vmc = vmlm. select. By(Label“xxx”); // return those members of the collection attached to the label View. Member. List. Manager now supports non item View. Members, i. e. Change. Packages, Traces

View. Configuration. Differ & View. Polling. Agent View. Configuration. Differ is used to compare

View. Configuration. Differ & View. Polling. Agent View. Configuration. Differ is used to compare two configurations of a given view, triggering Item, Folder and View. Member Update Events, describing the changes detected between the two configurations. View. Polling. Agent is used to periodically poll a given view for recent changes, triggering Item, Folder and View. Member Update Events describing the changes detected since the last poll. With this release of the SDK, both View. Configuration. Differ and View. Polling. Agent supports event notification for non item View. Members, i. e. Change. Packages and Traces. The two algorithms also support event notification for custom components. However, both these algorithms are memory intensive. A lightweight MPX listener, also new to this release of the SDK, may be a preferable alternative.

View. Configuration Used to open rolled back (i. e. snapshots from history) views View

View. Configuration Used to open rolled back (i. e. snapshots from history) views View v = s. find. Project(“Star. Draw”). get. Default. View(); // the ‘tip’ or current configuration of the view Label[] ll = v. get. Activelabels(); v = new View(v, View. Configuration. create. From(new Date. Time(2009, 00, 01)); // rolled back to Jan 01, 2009 v = new View(v, View. Configuration. create. From(ll[0]); // rolled back to the label; i. e. the exact moment in server history when the label was created v = new View(v, View. Configuration. create. Tip()); // revert back to the tip or current configuration Opening a rolled back view is expensive. Resources are allocated on the server and retained in the server cache until the view is closed. Rolled back views represent snapshots from history. New items cannot be added to a rolled back view. Existing items cannot be modified or deleted. Rolled back views are used extensively in View Compare Merge (VCM) to pick a fixed point in time at which the compare is executed, so as not to be influenced by subsequent changes to the tip.

Recycle Bin A recycle bin is a view that provides access to deleted items

Recycle Bin A recycle bin is a view that provides access to deleted items & deleted folders In addition to the standard view api’s, the Recycle. Bin exposes properties which allow applications to control the classes of active or deleted items that the Recycle. Bin should surface. Recycle. Bin r = view. get. Recycle. Bin(); r. set. Inclde. Active. Items(true); // Active items are excluded by default r. set. Include. Deleted. Items(true); // Deleted items are included by default r. set. Include. Deleted. Folders(true); // Deleted folders are included by default r. set. Deleted. As. Of(new Date. Time(2009/00/01)); // include everything deleted since Jan 01, 2009 // now, surface all active & deleted items in the root folder @see Item. is. Deleted() Item[] all = r. get. Root. Folder(). get. Items(cstm. Typ); The Recycle. Bin is extensively used in VCM to identify Item. Differences like ‘Deleted in {Source | Target}’ Note that deleted items are no longer available once a view has been purged.

Application The context of a client application. Creating a Server instance creates a default

Application The context of a client application. Creating a Server instance creates a default application instance Alternatively, create an Application instance, and one or more servers in its context. Particularly useful for creation and resolution of cross server Traces, federating trace servers, etc. Application a = new Application(“Micro. Focus Team Management”); Server s 1 = a. new. Server(“change. Request. Server. mydomain. com”, 49201); s 1. logon(…); Server s 2 = a. new. Server(“sctm. Server. mydomain. com”, 60000) ; s 2. logon(…); Server s 3 = a. new. Server(“trace. Server. mydomain. com”, 2000) ; s 3. logon(…); // find a change request in s 1, a test in s 2 & create a Trace between the two, store it in s 3 Trace t = new Trace(s 1. find. Project(“Federated. Traces”). get. Default. View()); t. set. Source(s 1. find. Project(“Defects”). get. Default. View(). find(s 1. get. Types(). CHANGE_REQUEST, 1234)); t. set. Target(s 2. find. Project(“Silk. Central”). get. Default. View(). find(s 2. get. Types(). find(“Test”), 5678)); t. update();

Application is also useful for resolving Star. Team Objects to URLs and URLs to

Application is also useful for resolving Star. Team Objects to URLs and URLs to Objects String url = a. to. Star. Team. URL(t); // save the url on your desktop, email it to a colleague, etc. Trace tt = (Trace)a. resolve(url); assert. True(t. equals(tt)); // verify that t is tt Star. Team URL’s are well formed URI’s with a formal grammar. Star. Team URLs use ID or NAME schemes starteam: //localhost: 49201/0; ns=Project; scheme=id/0; ns=View; scheme=id/197; ns=File; scheme=id; scope=full starteam: //be 5 ee 3 b 0 -c 719 -49 c 6 -a 1 a 1 f 493764 a 03 f 5; id=guid/0; ns=Project; scheme=id/0; ns=View; scheme=id/197; ns=File; scheme=id; scope=full starteam: //localhost: 49201/Project_12926 ffd 7 de/Folder_Application. Test. test. Resolve. URLS_1292 6 ffd 7 df/Folder_Application. Test. test. Resolve. URLS_12926 ffd 7 e 0/File_Application. Test. test. Resolve. URLS_12926 ffd 7 e 1. txt // NAME based URIs are best avoided; they are case sensitive, unwieldy, and not guaranteed to be unique

Workflow Star. Team Workflow specifies a set of type specific rules, states & state

Workflow Star. Team Workflow specifies a set of type specific rules, states & state transitions, which are described in XML files in the Star. Flow extensions project. The xml files are created using Workflow Designer. The workflow engine triggers the rules & validates the state transitions when attempting to update an item of the specified type. Application developers can turn on the workflow engine using the static api Workflow. from. Star. Flow. Extensions(View) which queries the starflow extensions project for the workflow, loads it up into memory & attaches it to the respective workflow aware types. An application can also directly load workflow from an. xml file produced by Workflow designer using any of the three from. File({Server|Project|View}, java. io. File) api’s. Once enabled, workflow cannot be disabled for the life of the application. An application may choose to verify that a workflow step will succeed, i. e. an artifact can be updated in a given step @see Workflow. can. Update(Typed. Resource). If a workflow enabled application attempts to update an artifact but can. Update() returns false, an SDK Runtime Exception will be thrown.

Events Asynchronous change notification delivered to the client application via standard event listeners All

Events Asynchronous change notification delivered to the client application via standard event listeners All event objects and event listeners are aggregated in the com. starteam. events namespace Client applications typically register for Folder, Item, View. Member or Server. Command notification Project, View, Filter, Query & Label notifications are also supported, but may occur less frequently Applications interested in receiving events create event handlers (implementing the appropriate listener interface) and register these handlers with the SDK. import com. starteam. events. *; import com. starteam. *; private class Item. Event. Handler implements Item. Listener { public void item. Added(Item. Event e) {…} … }

Events Item. Event. Handler ieh = new Item. Event. Handler(); assert. True(view. get. Server().

Events Item. Event. Handler ieh = new Item. Event. Handler(); assert. True(view. get. Server(). is. MPXEnabled()); // Item, Folder or View. Member Events only fire if MPX is enabled view. add. Item. Listener(ieh); … view. remove. Item. Listener(ieh); Folder. Update. Event. Handler fueh = new Folder. Update. Event. Listener() {…} // Item. Update, Folder. Update or View. Member. Update Events are not dependent upon MPX // They are triggered by explicit operations performed by the client application // for instance, View. refresh. Folders(), folder. update(), folder. remove() etc. might each trigger folder update events view. add. Folder. Update. Listener(fueh); … view. remove. Folder. Update. Listener(fueh);

MPX Events • • • An MPX-enabled SDK application can subscribe to specific server

MPX Events • • • An MPX-enabled SDK application can subscribe to specific server events (for example, an Item is added, modified or deleted), and provide event-handlers that are invoked when those events occur. The event-handling APIs support SDK applications that, without MPX publish/subscribe services, would be very difficult to write and prohibitively expensive to run. With MPX, an application simply registers an event handler, and waits for it to be invoked by the SDK. Event handling is supported in both the Java and C# APIs, using the standard Java or C# listener model. Listeners are always registered on an SDK object that defines the scope of interest. A given listener can also be registered at different levels of the SDK object hierarchy, providing the application with a great deal of flexibility in defining the scope of interest. The scope also defines the security context. Event-handlers use the same object model as the rest of the SDK; there is no way for an application to retrieve any data via an event-handler that it would not normally be able to retrieve outside the event-handler in the same security context. Event handlers are invoked from an event-handling thread that is separate from the main application thread. As a consequence, neither outgoing commands nor incoming events are capable of starving the other.

MPX Events A new class of Light weight MPX events are fired through a

MPX Events A new class of Light weight MPX events are fired through a Typed Resource Listener. Register for these events on the server instance. Useful for continuous monitoring tools (which may not require views to be left open), significantly reduce server load If the view is never opened on the server, events are never fired. Conversely if the event is fired, the application may now open the view, since it has already been opened on the server by some other application… private class Typed. Resource. Handler implements Typed. Resource. Listener { public void resource. Added(Typed. Resource. Event e) { …} } Typed. Resource. Handler trh = new Typed. Resource. Handler(); View v = s. find. Project(“Star. Draw”). get. Default. View(); s. add. Typed. Resource. Listener(trh, v, new Type. Collection() {s. get. Types(). FILE}); v. close(); // do not cache view, folder, file etc. resources either in the client or on the server … // keep monitoring for changes, do something if a change is detected, perhaps launch an automatic build // or send a notification message to an administrator s. remove. Typed. Resource. Listener(trh, v);

Star. Team Registry (Category) A structured store (hive), similar in function to the Windows

Star. Team Registry (Category) A structured store (hive), similar in function to the Windows registry, new to 12. 0+ servers. The registry consists of categories. A category may contain a set of (sub) categories. Categories & Sub Categories may be defined to any arbitrary depth. A category may contain Options are identified by (String) Keys and (Object) values. Values may be any of the standard programming language primitives (int, String, double etc) and/or serializable SDK value types like MD 5, Enumerated. Value etc. Category & Option key uniqueness is enforced in the parent category. Categories are implemented as Folders, Options are implemented using a private SDK component. Categories & Options may be locked & unlocked. Locking a category automatically locks all its descendant (sub) categories including all options in the tree. Access to categories andoptions can be managed with Access Rights. A global System wide registry may be accessed from the Server (@see Server. get. Registry() Each view may also implement its own registry. (@see View. get. Registry())

Components The Star. Team Server manages server side components. Instances of these components ‘data

Components The Star. Team Server manages server side components. Instances of these components ‘data objects’ are called artifacts. Components may subscribe to one or more services including Persistence and Versioning; i. e. artifacts may be accessed via generic queries and transacted updates Item Configuration; i. e. artifacts may support branching, sharing and/or organization within folders Minimally, items support locking, label attachment and addressability via links or traces. Attachments; i. e. non versioned files used to annotate or supplement an artifact Bookmarks; i. e. users may flag certain artifacts for searching and tracking Notifications; i. e. subscription services that support email and status notifications to be delivered based on specific state changes of selected property values. Artifacts defined by components are automatically registered in the server’s component catalog.

Components All Star. Team (stock &/or custom) components have a common set of properties.

Components All Star. Team (stock &/or custom) components have a common set of properties. These include View Member ID – a server wide, unique ID Root Object ID – the shared ID for all members of a given reference (share) tree Object ID – the shared ID for all members of a given branch Parent Revision Number – for branchable types, the parent revision at which the resource was branched Dot Notation – a String based annotation describing an object’s position in its share tree Created By, Modified By, Deleted By – the User who created, modified or deleted this object Created At, Modified At, Deleted At – the Date and Time that the object was created, modified or deleted. Revision Number – a sequential counter issued to each revision of a given object (when an object is updated, i. e. one or more of its property values are changed, a new revision of the object is created) In addition, each stock component has a fixed, out of the box set of properties that annotate the type.

Stock Components Stock components (types) are bundled with Star. Team and shipped with a

Stock Components Stock components (types) are bundled with Star. Team and shipped with a pre-defined set of properties. Stock components are customizable. An application can add custom properties to any stock component. Files and Change. Requests are Items. Requirements, Tasks and Topics are Tree Items may form regular top down trees, but not graphs. i. e. a task may have several sub-tasks, but a task can have only a single parent (task). Items are branchable; Tree Items are not. Folders are a bit of an anomaly. Folders are branchable containers. Folders may contain sub folders (tree like behavior) and any/all other item or tree item types. for example, a given folder can contain 3 sub folders, 5 Files, 2 Change Requests, a tree of 3 Tasks (parent-child-grandchild), a single stand alone Task and 1 Requirement Note that a given tree (of Tree Items) cannot span folders, but distinct trees may reside in different folders. For simplicity, the SDK models Folders and Tree Items as Items.

Stock Components – Files & Folders The file type includes properties like Name, Description,

Stock Components – Files & Folders The file type includes properties like Name, Description, Size, MD 5, & Hive. ID. File content is managed by the server on a file system called a vault, which is organized by hives. Unlike other Star. Team components, file objects have a client side representation, namely, physical files in the local file system (workspace) on disk. Accordingly, files have client side properties such as full (path qualified) name, working file size, MD 5 & modified time. To track differences between the working file on disk and its representation in the Star. Team Vault, the File type has a Status property, with values like CURRENT (content on disk is identical to that in the vault), MODIFIED (content on disk is newer than that in the vault) and OUT_OF_DATE (content on disk is older than that in the vault) The folder type includes properties like Name, Description & Path. Folders too have a client side representation, namely, working folders on disk. However, non file applications need not surface this client side representation, treating folders strictly as organizational containers (drawers) of Star. Team components. The SDK maps the client / server representations of Files & Folders. The Star. Team server itself is completely unaware of an existing client side representation. The file system is of course unaware of a server representation.

Stock Components – Change Requests, Requirements and Tasks are a class of Process Items.

Stock Components – Change Requests, Requirements and Tasks are a class of Process Items. When a set of files is checked in, the set is associated with a Process Item in a given state. As part of the checkin, the Process Item may be transitioned to a different state. So for instance, a group of files can be checked in against a Change Request in an Open State (the Status Property value of the Change Request) and the Status Property value may be moved to a Fixed State. Currently, Custom Components cannot be used as Process Items. The Change Request Type includes properties such as Platform – applicable Operating System Platform Severity – High, Medium or Low Responsibility – the User responsible for addressing this request Synopsis – a brief description of the request Request Type – Suggestion or Defect

Stock Components – Requirements, Tasks & Topics The Requirement Type includes properties like High

Stock Components – Requirements, Tasks & Topics The Requirement Type includes properties like High & Low Effort Estimates, Expected Effort Owner – the User who owns this Requirement Responsible Users – the users responsible for implementing this requirement Notes Number of identified Ambiguities The Task Type includes properties like Actual Start & Finish Dates, Estimated Start & Finish Dates Resources – the set of Users assigned to the Task Successor and Predecessor Task Dependencies & Work. Records Task. Dependencies & Workrecord queries are bulkified & the types are MPX Enabled for 12. 0 servers+. Threaded Topics include the Recipients property & the text (content) of the topic Topics can be used as discussion boards Notification is automatically sent via email or displayed on the toolbar. Stock components are nothing more than shrink wrapped custom components!

Custom Components can be created & ‘dropped into’ the 12. 0 server by the

Custom Components can be created & ‘dropped into’ the 12. 0 server by the component developer. The custom component schema is described using a well formed xml definition, published by server engineering (They may also be created using the SDK api Server. create. Type(String, boolean). ) Custom Components are either Branchable (Item) types or Tree(Item) types Item. Type cstm. Typ = s. get. Types(). find(“My. Custom. Component”); // type metadata for the new component Property. Collection prprtys = cstm. Typ. get. Properties(); // property metadata for this component View. Member. Collection vmc = fldr. get. Items(cstm. Typ); // instances of this custom type in a collection The SDK knows nothing about Custom Components, except in the most generic way. Out of the box, the custom component shows up as an SDK Item or Tree. Item Type, and can be manipulated using the standard get. Value/set. Value accessors. New instance may be created using Item. Type. create. Item(Folder) // Tree. Items are Items with two useful additional properties Tree. Item[] kids = itm. get. Children(); // returns a list of the immediate children of this tree item instance Tree. Item prnt = itm. get. Parent(); // returns the immediate parent of this tree item or NULL if this is a root

Custom Components Standard CRUD operations can be performed using standard methods like View. Member.

Custom Components Standard CRUD operations can be performed using standard methods like View. Member. update() & View. Member. remove() on custom component instances. Custom component instances can be fetched using either View. Member. Collection Folder. get. Items(Item. Type) or View. Member. Collection View. get. View. Members(View. Member. Type) Their properties can be populated using either Folder. populate(Item. Type, Property. Collection, int) or View. Member. Collection. get. Cache(). populate(Property. Collection) Their properties can be refreshed using either Folder. refresh. Items(Item. Type, Property. Collection, int) or View. Member. Collection. get. Cache(). refresh(Property. Collection) Out of the box, an application developer treats custom components no differently than (say) Change. Request or Task

Custom Components The server automatically provides a set of ‘common’ or ‘stock’ properties for

Custom Components The server automatically provides a set of ‘common’ or ‘stock’ properties for a custom component. Property Name Server Type SDK Type ID int Integer Property Created. Time decimal Date. Time Property Created. User. ID int User (Object) Property Deleted. Time decimal Date. Time Property Deleted. User. ID int User (Object) Property Modified. Time decimal Date. Time Property Modified. User. ID int User (Object) Property End. Modified. Time decimal Date. Time Property Revision. Number int Integer Property Revision. Flags int Integer Property Short. Comment text String Property

Custom Components // Common Properties (contd)… Property Name Comment ID Attatchment. Count Attachment. IDs

Custom Components // Common Properties (contd)… Property Name Comment ID Attatchment. Count Attachment. IDs Attachment. Names Notification. Count Notification. IDs <Component. Type. Name>ID Dot. Notation Configuration. Time Server Type varchar int varbinary int varchar decimal SDK Type Text Property Integer Property Object Array Property Integer Property Text Property Date. Time Property

Custom Components // Server Calculated Common Properties… Property Name Server Type Read. Only bool

Custom Components // Server Calculated Common Properties… Property Name Server Type Read. Only bool Exclusive Locker int Non. Exclusive. Lockers varchar Branch. On. Change int Branch. State int Share. State int Item. Deleted. Time decimal Item. Deleted. User. ID int Read. Status. User. List varbinary Flag. User. List varbinary SDK Type Boolean Property Object Property Text Property Enumerated Property (User) Object Property Date. Time Property Object Array Property Object Property

Custom Components In addition to the common properties, Branchable Custom Component Types have the

Custom Components In addition to the common properties, Branchable Custom Component Types have the following specific additional properties Root. Object. ID int Integer Property Parent. Revision int Integer Property Path. Revision int Integer Property View. ID int Integer Property Tree Item Custom Component Types have a specific property identifying the parent tree item ID Parent. ID int Integer Property

Custom Components (Extending the Object Model) Application Developers may choose to extend the SDK

Custom Components (Extending the Object Model) Application Developers may choose to extend the SDK Object model, providing class definitions for custom Components. These definitions belong to the client developers namespace, but are treated as first class SDK citizens! NOTE: The custom component MUST have been created on the server before client implementation package com. microfocus. team. Define; import com. starteam. *; public class Visualization extends Tree. Item { private static final String my. Type. Name = “VISUALIZATION”; // This name MUST match the type name specified // in the component. xml definition public Visualization(Folder parent. Folder) { super(my. Type. Name , parent. Folder); // this base class constructor must be called } public Visualization(Visualization parent) { super(parent); // and so must this one } // add other apis’ as necessary, extend the Star. Team Type Model implement Client Calculated Properties, if any

Developing Custom Components The Application Developer may extend the Type Model for the custom

Developing Custom Components The Application Developer may extend the Type Model for the custom components. (This static class is a member of the component class) public static class Type extends com. starteam. {Tree}Item. Type { public static final String NAME = my. Type. Name; // and assign the type the name public Type(Server s, Type. Meta. Data d) { super(s, d); } Add property definitions for custom properties (specified through the xml definition) & client calculated properties Integer, Long. Integer, Double & Text Properties may be sub-classed to create custom client calculated properties public static class My. Client. Calculated. Property extends Integer. Property {…} Any property type definition can be sub-classed for custom properties public static class My. Custom. Content. Property extends Content. Property {…}

Developing Custom Components The Application Developer may also extend the Property Model for the

Developing Custom Components The Application Developer may also extend the Property Model for the custom component. This static class is a member of the type class, which is a static member of the component class public static class Property. Collection extends Item. Type. Property. Collection { public final My. Custom. Content. Property MY_CUSTOM_CONTENT; protected Property. Collection(Visualization. Type t, Property[] pp) { super(t, pp); set. Read. Only(false); // add the client calculated properties, if any add(new My. Client. Calculated. Property (t); set. Read. Only(true); MY_CUSTOM_CONTENT = (My. Custom. Content. Property)find(My. Custom. Content. Property. NAME); }

Developing Custom Components Extending the Property Model (continued) protected Property. Collection(Visualization. Type t, Property[]

Developing Custom Components Extending the Property Model (continued) protected Property. Collection(Visualization. Type t, Property[] pp) { super(t, pp); set. Read. Only(false); // & add the custom calculated properties add(new My. Client. Calculated. Property (t)); set. Read. Only(true); } // override Item. new. Property. Collection protected com. starteam. Property. Collection new Property. Collection(Property[] pp) { return new Property. Collection(this, pp); } // hook the new property into the model protected Property get. Property(com. starteam. Property. Meta. Data pd) { if (pd. to. String(). equals(My. Custom. Content. Property. NAME) return new My. Custom. Content. Property(this, pd); return super. get. Property(pd); } } }

Developing Custom Components Client calculated properties are properties injected into the component instance cache.

Developing Custom Components Client calculated properties are properties injected into the component instance cache. Their values are calculated on the client, typically involving client resources or aggregations of server properties Overide View. Member: : invoke() to hook in client calculated properties public Object invoke(String method) { if (Visualization. Type. My. Client. Calculated. Property. NAME. equals(method)) return new Integer(do. Some. Math()); // call a method that does some calculation return super. invoke(method); // or pass it down } private int do. Some. Math() { return new Random(). next. Int(); } // and the value of a client calculated property can be queried through Item. get. Value() Property clnt. Clc. Prprty = my. Object. get. Type(). get. Properties(). MY_CLIENT_CALCULATED; Integer some. Math = my. Object. get. Value(clnt. Clc. Prprty); // &/or by iterating over the Property. Collection pc = get. Server(). get. Types(). find(Visualization. Type. NAME). get. Properties(); for (int i = 0; i < pc. length; i++) { my. Object. get. Value((Property)pc. get(i)); }

Developing Custom Components // Declare the custom component class to the SDK before connecting

Developing Custom Components // Declare the custom component class to the SDK before connecting to the server s. declare. Component. Definition(Visualization. Type. NAME, Visualization. class); // and when writing your code, you can now cast to a custom type, and a call to get. Value(Client. Calculated. Property) calculates & returns a value from a method provided in the custom class get. Value(Custom. Component. Property) returns the value of the property whose definition is in the custom class i. e. the SDK treats custom component definitions from an enclosing namespace as first class SDK citizens View. Member. Collection vmc = fldr. get. Items(cstm. Typ); // returns instances of this type in a collection for (int i = 0; i < vmc. size(); i++) { Visualization itm = (Visualization)vmc. get. At(i); // component instances are returned as Visualization objects } // If Visualization is not a Tree Item Component, i. e. Visualization extends Item, then only one constructor is required public Visualization(Folder parent. Folder) { super(my. Type. Name , parent. Folder); // and this base class constructor must be called }

Developing Custom Components The application developer can work with custom components definitions from any

Developing Custom Components The application developer can work with custom components definitions from any namespace just as if they were stock components from the SDK namespace Visualization. Type vs. Typ = (Visualization. Type)s. get. Types(). find(Visualization. Type. NAME); Vizualization[] vv = (Visualization[])fldr. get. Items(vs. Typ). to. Array(new Visualization[0]); Visualization. Type. Property. Collection pc = (Visualization. Type. Property. Collection)vs. Typ. get. Properties(); Property my. Cstm. Cntnt. Prprty = pc. MY_CUSTOM_CONTENT; My. Custom. Content. Property prprty = (My. Custom. Content. Property)pc. find(My. Custom. Content. Property. NAME); Content cntnt = vv[0]. get. Value(prprty); Visualization vz = vs. Typ. create. Item(my. Folder); vz. . set. Value(someproperty, “its value”); vz. update();

Developing Custom Components Property Definitions for Client Calculated Properties – Property IDs MUST BE

Developing Custom Components Property Definitions for Client Calculated Properties – Property IDs MUST BE UNIQUE across the Type Assign each Client Calculated Property a unique incremented ID based on Property. CLIENT_CALCULATED • static final class Calculated. Weight. Property extends Integer. Property { • • private static final int CALCULATED_WEIGHT_id = com. starteam. Property. CLIENT_CALCULATED + 1; protected Calculated. Weight. Property(Type owner) { super(owner, CALCULATED_WEIGHT_id, NAME); } • • public static final String NAME = "Calculated Weight" /*NOI 18 N*/; }

Developing Custom Components Property Definitions for Custom Properties – extend the only protected constructor

Developing Custom Components Property Definitions for Custom Properties – extend the only protected constructor visible from com. starteam • public static final class My. Integer. Property extends Integer. Property { • My. Integer. Property(com. starteam. Type owner, com. starteam. Property. Meta. Data data) { – super(owner, data); } • • public static final String NAME = "Usr_My. Integer“ /*NOI 18 N*/; } Note that Enumerated Properties need special code to handle conversions from com. starteam. Enumerated. Value to equivalent strongly typed class definitions which sub-class Enumerated. Value @see embedded code in the next slide

Developing Custom Components // An example of sub-classing Enumerated Value • public static final

Developing Custom Components // An example of sub-classing Enumerated Value • public static final class Star. Flow. Status extends Enumerated. Value { – private int m_id; – private Star. Flow. Status(int id) { m_id = id; } – public int get. ID() {return m_id; } – public final static Star. Flow. Status ENTERED = new Star. Flow. Status(100); public final static Star. Flow. Status NEW = new Star. Flow. Status(110); – public static final Star. Flow. Status[] ALL = new Star. Flow. Status[] {ENTERED, NEW}; – public static Star. Flow. Status from. Value(Enumerated. Value value) {…} – public static Star. Flow. Status from. ID(int id) {…} – public boolean equals(Object o) {…} – public int hash. Code() {return m_id; } • }

Checkin Manager • Uses a transactional model to add and checkin files, move and/or

Checkin Manager • Uses a transactional model to add and checkin files, move and/or remove items on the starteam server. • The public api’s build up the internal state of the manager, without executing a server call. • mgr. checkin(file); • mgr. checkin(file, new checkin. Options()); // assign checkin options to file • mgr. checkin. From(file, new java. io. File(“c: //temp/”)); // assign different alternate path to file • mgr. ignore(file); // remove file from consideration for checkin • mgr. remove(item); // remove Item from the server • mgr. move. To(item, folder); // move Item to Folder on the server

Checkin Manager • can. Commit() returns false if a subsequent commit() will fail; for

Checkin Manager • can. Commit() returns false if a subsequent commit() will fail; for instance, if a File is in an UNKNOWN state, and the force checkin flag is off, or if there is nothing to commit • commit() makes the least number of server calls entirely within a transaction. May comprise of several remove(), move. To() and checkin() operations on the server. If an error occurs, the entire transaction is rolled back. • A successful commit() creates a Change. Package in the target view. Each change in the change collection maps the previous (pre commit) revision of the item to the committed revision. The source and target revisions of each change are in the same (target) view. • If a Process Item is specified, a Trace links the Change Package to the Process Item. • The resultant Change Package may be replayed as a VCM Promote, Rebase or Replicate. • Optimized to use all available bulk commands

Checkout Manager • The various overloads of checkout(…) build up internal state of the

Checkout Manager • The various overloads of checkout(…) build up internal state of the manager, without executing a server call • Multiple calls to checkout() for the same file overwrite the in-memory internal state accordingly • mgr. checkout(file); • mgr. checkout(file, new checkout. Options()); // assign checkout options to file • mgr. checkout. To(file, new java. io. File(“c: //temp/”)); // assign different alternate checkout path to file • mgr. ignore(file); // remove file from consideration for checkout

Checkout Manager • can. Commit() returns false if a subsequent commit() will fail; –

Checkout Manager • can. Commit() returns false if a subsequent commit() will fail; – for instance, if a File is in an UNKNOWN state, and the force checkout flag is off, or if there is nothing to commit • commit() actually executes the checkout. Unlike Checkin. Manager, this commit() is non-transactional. The result of a partial or aborted checkout can leave local files on the file system in an indeterminate state. – If a network near Cache. Agent is available, Checkout. Manager will automatically fetch file content from the Cache Agent. • Optimized to use all available bulk commands, and use the least number of server calls.

View Compare Merge • • • The VCM APIs allow an application to compare

View Compare Merge • • • The VCM APIs allow an application to compare two views, and merge differences from one to the other. A typical view compare/merge (VCM) application will perform the following steps: Construct a VCM session, specifying the merge type and the source and target views. In a compare only session, you may specify two different configurations of the same view. Set the scope of the session, if necessary. By default, all files and folders are in scope. Change the default VCM options, if necessary. Options determine whether or not file content will be merged automatically, whether source and target items will be locked, and so on. Compare the two views. Examine the resulting differences. Each difference indicates the source and target items, the difference type, and the recommended action. You may accept the default action, or overide it with any other legal action. Commit the session. This executes the actions specified for each difference, merging changes to the target view. The changes are executed as a single atomic transaction. When the session is committed, Star. Team creates a Change. Package in the target view to record the changes. The Change. Package includes new file and folder revisions; copies of the difference and update reports are included as attachments, as is an exported session file that can be used for future reference. The committed Change. Package can subsequently be re-opened in a read-only mode, and differences between pre & post committed files can be reviewed, thus providing an audit trail of changes as they propagate through the system.

View Compare Merge • An example of using VCM import com. starteam. *; import

View Compare Merge • An example of using VCM import com. starteam. *; import com. starteam. viewcomparemerge. *; Server s = new Server(“host”, port); s. log. On(“user”, “password”); Project p = s. find. Project(“Star. Draw”); View v = p. find. View(“Release 1. 0 Maintenance”); Session n = new Session(Merge. Type. Promote, p. get. Default. View(), v); n. compare(); // defaults to Files & Folders, @see Session. set. Scope(Scope) Item. Difference[] ii = n. get. Differences(); // for, ensure that each Item. Difference can be committed n. commit(); // executes in a transaction, creates a Change. Package when done n. close(); // release all resources, close open views, etc.

Command Processor • • • A state-ful implementation in the SDK (augments the state-less

Command Processor • • • A state-ful implementation in the SDK (augments the state-less implementation from earlier releases) Fully backward compatible with existing commands from stcmd Automatically supports MPX, Cache Agent, file & object property content Automatically supports transactions, bulk commands Refactor existing scripts to benefit from maintaining cross command state e. g. … connect [username[: password]@]address: port [password. From. File password. File] [store. Password. To. File password. File] [case. Sensitive. Folders | -csf] [encryption = RC 4|RC 2_ECB|RC 2_CBC|RC 2_FCB][compression | -cmp] [mpx=on|off (default ON) profile=profile. Name [cache. Agent@address: port (default auto. Locate] | =off] [mode [lock | exlock | unlock]] • set project=project. Name [view=view. Name | view. Hierarchy=view. Name: …] [folder. Hierarchy=folder. Name: . . ] [-cfgl "label" | -cfgp "promotion state" | -cfgd "date"] // … run commands e. g. select, checkin, checkout, etc • disconnect Use the ‘new’ stcmd from a Windows Command Prompt, Unix shell… Use Command. Processor directly from ant, hudson, javascript, etc.

Command Processor • A new generalized SQL like query syntax select * | access-rights

Command Processor • A new generalized SQL like query syntax select * | access-rights | {property. Name, . . . } | filter = 'my. Filter' from type {history} {deleted} {at [label “label. Name” | promotionstate “promotion. State. Name” | datetime “date. Time. Value” pattern “pattern. Value”]} {into “output. File. Path” {separator ’field. Separator’}} where { {attached-label = 'mylabel‘ | query = 'myquery' } {and} {folder = 'myfolder' {recurse} or folder = 'myfolderhierarchy' {recurse} or folder =. {recurse}} or. . . }} order by {property. Name, . . . } | orderfilter = 'my. Order. Filter' • type {File | Folder | Change. Request | Requirement | Task | Topic | Change. Package | Trace | Custom. Component}

Command Processor • A new generalized SQL like syntax for (transacted) bulk inserts insert

Command Processor • A new generalized SQL like syntax for (transacted) bulk inserts insert into type {output * | {property. Name, . . . } | filter = 'my. Filter‘ into “output. File. Path” {separator ’field. Separator’}} ( property. Name, … ) values [( value, … ) | from ‘input. File. Path’] • type {Folder | Change. Request | Requirement | Task | Topic | Custom. Component} • Creates a Checkin Change Package

Command Processor • A new generalized SQL like syntax for (transacted) bulk updates update

Command Processor • A new generalized SQL like syntax for (transacted) bulk updates update type { output * | {property. Name, . . . } | filter = 'my. Filter‘ into “output. File. Path” {separator ’field. Separator’}} set property. Name = value, … where { query = 'myquery' {and} {folder = 'myfolder' {recurse} or folder = 'myfolderhierarchy' {recurse} or folder =. {recurse}} or. . . }} • type {File | Folder | Change. Request | Requirement | Task | Topic | Change. Package | Trace | Custom. Component} • Creates a Checkin Change Package

Command Processor • A new generalized SQL like syntax for (transacted) bulk deletes delete

Command Processor • A new generalized SQL like syntax for (transacted) bulk deletes delete type { local } { output * | {property. Name, . . . } | filter = 'my. Filter‘ into “output. File. Path” {separator ’field. Separator’}} where { query = 'myquery' {and} {folder = 'myfolder' {recurse} or folder = 'myfolderhierarchy' {recurse} or folder =. {recurse}} or. . . }} • type {File | Folder | Change. Request | Requirement | Task | Topic | Custom. Component} • Creates a Checkin Change Package

Command Processor • • • A new command for workspace and/or view synchronization sync

Command Processor • • • A new command for workspace and/or view synchronization sync workspace|view|both [-o] [-nivf] [-l | -u | -nel] [-vl "label. Name"] [-nomove] [-r "comment" | -rf "file. Name"] [[ -active | [-cr | -req | -task ] process. Item. Path] [-mark]] The sync{hronize} command is used to catch up with changes in the view and propagate them to the workspace (the user’s working folders on disk), and/or, to catch up with changes in the workspace and propagate them to the view. If only workspace is specified, the users working folders on disk are updated to reflect changes in the view, the view itself is unchanged. If only view is specified, then the view is updated to reflect changes in the workspace, the workspace is left unchanged. If both are specified, then changes are propagated in both directions. In any case, the post-sync state of the workspace & the view are structurally identical. • • Operations that occur on synchronization include checkout of date &/or missing files and folders; checkin of new &/or modified files & folders. (checkin operations will produce a checkin change package) • • • –o forces an overwrite on checkin or checkout, and breaks merge conflicts -nivf turns on not in view folders, and is only relevant if the view is being updated. The rest of the parameters are only relevant if the view is being updated, and satisfy process rules

Command Processor Examples • • • connect localhost: 49201 set project = ‘Star. Draw’

Command Processor Examples • • • connect localhost: 49201 set project = ‘Star. Draw’ view = ‘Release 1. 0 Maintenance’ apply-label -is -lbl Web 1 files diff -is -w -vl "New Step 2 select * from changerequest into “c: /temp/Query. Output. txt” separator ; select Name, Status, ‘File Time Stamp at Check-in’ from file where query = ‘Files to Check In’ select filter = ‘By Status and Responsibility’ from task where folder = ‘Sales Materials’ or folder = ‘Marketing Materials’ recurse update changerequest set synopsis = ‘foo’ where query = ‘Status = Open’ delete changerequest where query = ‘Status = Open’ disconnect

Artifact Cache • A managed collection of typed artifacts & access rights • Tip

Artifact Cache • A managed collection of typed artifacts & access rights • Tip caches are self refreshing. Baseline (rolled back) caches are invariant (i. e read only) w. r. t. time. • Fully loaded & built up in the context of an Administrator, shared across all users, including those at lesser privileges • Build up the cache using cache. View. Members(Web. Cache. View, Web. Cache. View. Member. Type[]); // manage all View. Members of the specified type(s) in the view • Query the Cache using the api. – Web. Cache. View. Member vm = find. Web. Cache. View. Member(Web. Cache. User, int);

Artifact Cache Manager • A managed collection of Artifact Caches. • Manages a single

Artifact Cache Manager • A managed collection of Artifact Caches. • Manages a single Artifact Cache Manager per server, which contains a Tip Cache and as many historical caches as requested • Register the Cache Manager for a given server • Manages all Tip, i. e. Current Projects, Views, etc in the Tip Cache • Manages a rolled back view (based on label, promotion state or date time) in its own (baseline) cache • Discards historical caches after a specified unused expiration window • Manages web ‘client’ applications that share Artifact Caches • Artifact Cache Manager, Artifact Cache & the Web. Cache object model provide a thread safe connection pool mechanism for developing scalable multi user web applications • Walk the model starting from the Administrative Context, which returns a Web. Cache. Server, Web. Cache. Projects, etc…

Web Cache Artifact Model

Web Cache Artifact Model

Web Cache Artifact Model • The web artifacts are wrappers around and peers to

Web Cache Artifact Model • The web artifacts are wrappers around and peers to the core SDK artifacts. There is a 1 to 1 mapping between objects at each level. • The model is complimentary. From the Context, the application developer can seamlessly switch between Web. Cache objects and their native peer’s and vice versa. (@see Artifact. Cache. Manager. Context) • The programming metaphor for web and peer objects is identical and could almost be swapped in place. • All server calls are issued through the connection pool • The web cache model forms the basis for the new Micro. Focus web applications currently being developed (code name Topaz) • But customers can use the model to develop their own web applications.

12. 0 Feature Set New SDK namespace, fully revamped, consistent object model New command

12. 0 Feature Set New SDK namespace, fully revamped, consistent object model New command line (with rich SQL like extensions) Workflow support & Checkin Change Packages New Web Application Development Model 64 bit SDK. jar The 12. 0 SDK is fully backward compatible with the 11. 0 server. The 12. 0 Server is fully backward compatible with the 11. 0 SDK. New to the 12. 0 Server Custom Components & the Registry Content & Map Properties Multi Select & Hierarchical Enumerations, Date Properties

12. 0 Feature Set New to the 12. 0 Server (continued) Bulk Queries for

12. 0 Feature Set New to the 12. 0 Server (continued) Bulk Queries for History, Locking, Behavior, User Group Relationships Work Records, Task Dependencies MPX enabled Groups, Access Rights Work Records & Task Dependencies Move & Share Access Rights Split Attachments in the Vault

12. 0 Feature Set The old (com. starbase) SDK. jar is still available through

12. 0 Feature Set The old (com. starbase) SDK. jar is still available through at least 1 release cycle to support APEs. Custom application developers are encouraged to port their applications to the new object model and namespace. A forum for Star. Team customers to answer SDK related questions & post regular SDK beta builds is now available. http: //community. microfocus. com/Forums/18_Star. Team

Star. Team SDK 12. 0 Reprise • A fully object centric new namespace •

Star. Team SDK 12. 0 Reprise • A fully object centric new namespace • Backward compatible with 11. 0 servers, forward compatible from 12. 0+ servers • Native Java & C# frameworks. • Supports web application development • Supports UI free back office development • Supports client specific GUI development