XOG Services: Object API

ccppmop159
The structure for each XOG object is defined in its corresponding schema (XSD). One general schema definition is defined for all read object requests. However, the schema definition for each read object response and each write object request varies based on the object that is accessed. This variation happens because the structure for each object is defined in its own corresponding schema.
For a complete list of available XOG objects, see XOG Object Reference.
XOG Object Types
The Object API includes these groups of XOG objects:
  • Standard stock objects
    . Refers to actual objects in the XOG. You can communicate with these standard stock objects by reading and writing data using a valid interface.
  • Custom objects and add-ins
    . These objects have unique schemas that are different from the standard stock object schema. First create custom objects in Studio before you can invoke them through the XOG. Add-in schemas allow you to read and write Studio components such as objects, pages, and portlets.
For more information, see
Classic PPM
 
Studio Development
.
ActionObject Element
All read and write XOG objects use an <
ActionObject>
element to define the action to be taken and the object to take it on. An action can be either a read or write. An object can be any XOG object that is available under the Objects API category such as department and companies. For example,
the
<ReadProject>
element indicates read as the action to take, and Project is the XOG object against which the action is taken. The
<ActionObject>
element is the parent element that wraps around the NikuDataBus header attributes.
This example shows the structure that is used for requesting a read action on the Project object:
<obj:ReadProject xmlns:obj="http://www.niku.com/xog/Object"> <NikuDataBus> <Header/> <Query/> </NikuDataBus> </obj:ReadProject>
The namespace
http://www.niku.com/xog/Object
must be localized in your request file to the
<ActionObject>
element. This localization is accomplished with the obj prefix. If you do not include this prefix, you see an error during the processing of the request.
Read Standard Stock Objects
Read object requests are used to extract specific object records from 
Classic PPM
.
Example XML Read Request
The read object request services reference the nikuxog_read.xsd schema in this example:
<obj:ReadUser xmlns:obj="http://www.niku.com/xog/Object"> <NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_read.xsd"> <Header version="12.0.0.5028" externalSource="NIKU"/> <Query> <Filter name="userName" criteria="EQUALS">admin</Filter> </Query> </NikuDataBus> </obj:ReadUser>
Example XML Read Response
In this example, the nikuxog_user.xsd defines the NikuDataBus read response element.
<ReadUserResponse xmlns="http://www.niku.com/xog/Object"> <NikuDataBus xsi:noNamespaceSchemaLocation="../xsd/nikuxog_user.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Header externalSource="NIKU" version="12.0.0.5028"/> <Users> <User externalId=" " userLanguage="English" userLocale="en_US" userName="admin" userStatus="ACTIVE" userTimezone="Europe/London" userType="INTERNAL"> <PersonalInformation emailAddress="[email protected]" firstName="ca" lastName="Administrator"/> <Resource resourceId="admin"/> <Company/> <General addedBy="admin" addedDate="2005-03-12"/> <OBSAssocs> <OBSAssoc id="loc" name="Location" unitPath="/ USA"/> </OBSAssocs> <Groups> <Group id="ApplAdminRl"/> </Groups> <GlobalRights/> <InstanceRights/> <InstanceOBSRights> </User> </Users> <XOGOutput> <Status state="SUCCESS"/> <Statistics failureRecords="0"insertedRecords="0" totalNumberOfRecords="1" updatedRecords="0"/> <Records/>' </XOGOutput> </NikuDataBus> </ReadUserResponse>
Write Standard Stock Objects
Write object requests are used to insert and update records into another system.
Example XML Write Request
In the XML write requests, the unique record identifier varies based on the object. In this example, the identifier is the
userName
attribute. This example is an update, and it includes only a subset of the information that is exported in the read request example. The nikuxog_user.xsd defines the NikuDataBus write request element.
<obj:WriteUser xmlns:obj="http://www.niku.com/xog/Object"> <NikuDataBus xsi:noNamespaceSchemaLocation="../xsd/nikuxog_user.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Header externalSource="NIKU" version="12.0.0.5028"/> <Users> <User externalId=" " userLanguage="English" userLocale="en_US" userName="admin" userStatus="ACTIVE" userTimezone="Europe/London"> <PersonalInformation emailAddress="[email protected]"/> </User> </Users> </NikuDataBus> </obj:WriteUser>
Example XML Write Response
This example is the result from the example write request.
<WriteUserResponse xmlns="http://www.niku.com/xog/Object"> <XOGOutput xsi:noNamespaceSchemaLocation="../xsd/status.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Object type="user"/> <Status state="SUCCESS"/> <Statistics failureRecords="0" insertedRecords="0" totalNumberOfRecords="1" updatedRecords="1"/> <Records> <Record> <KeyInformation> <column name="ALL">ALL RECORDS</column> </KeyInformation> <ErrorInformation> <Severity>WARNING</Severity> <Description>New Users Password will be Defaulted to Value ca2000</Description> </ErrorInformation> </Record> </Records> </XOGOutput> </WriteUserResponse>
Partitioning and Standard Stock Objects
The read object response services provide partition view information for each object instance. Similarly, you can write a partition view to each write object instance request. If you do not specify a partition view in your write request, all of the instances that you create are automatically assigned to the default system partition value NIKU.ROOT. To specify a new partition, replace NIKU.ROOT with your partition code. Before you can specify a partition view, create a partition model and associate it with your objects in Studio.
For more information, see
Classic PPM
 
Studio Development
.
Example Partition XML
This example shows how partition information is specified for each object instance (for each
Project
) using the <CustomInformation> element.
<obj:WriteProject xmlns:obj="http://www.niku.com/xog/Object"> <NikuDataBus xsi:noNamespaceSchemaLocation="../xsd/nikuxog_user.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Header externalSource="NIKU" version="8.0"/> <Projects> <Project> . . . . <CustomInformation> <ColumnValue name="partition_code">NIKU.ROOT</ColumnValue> </CustomInformation> . . . . </Project> </Projectss> </NikuDataBus> </obj:WriteProject>
Read and Write Custom Object Instances
The CustomObjectInstances service is an entry point to enable XOG communication with instances of custom objects. Instances represent data that is held within custom objects, not the definition of the objects.
For more information, see
Classic PPM
 
Studio Development
.
Read CustomObjectInstances
A CustomObjectInstances read request requires the
namespace niku_xog_read.xsd
and then the
<CustomObjectInstanceQuery>
element. The CustomObjectInstanceQuery element allows you to filter on instances of one or more custom objects using these filter attributes:
  • objectCode
    . Refers to the custom object ID as defined in Studio.
  • instanceCode
    . Refers to the custom object instance ID as defined in Studio.
For more information, see
Classic PPM
 
Studio Development
.
Example XML Read Request
This XML sample shows an example read CustomObjectInstance request and how it uses the <CustomObjectInstanceQuery> element.
<obj:ReadCustomObjectInstance xmlns:obj="http://www.niku.com/xog/Object"> <NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_read.xsd"> <Header version="12.0.0.5028" externalSource="NIKU"/> <CustomObjectInstanceQuery> <Filter name="objectCode" criteria="EQUALS">training_modules</Filter> <Filter name="instanceCode" criteria="EQUALS">Business Ethics </Filter> </CustomObjectInstanceQuery> </NikuDataBus> </obj:ReadCustomObjectInstance>
Write CustomObjectInstances
The write CustomObjectInstances request services are defined by the
nikuxog_customObjectInstance.xsd
schema.
Example Write XML
This example shows an XML write request:
<obj:WriteCustomObjectInstance xmlns:obj="http://www.niku.com/ xog/Object"> <NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/ nikuxog_customObjectInstance.xsd"> <Header externalSource="NIKU" version="12.0.0.5028"/> <customObjectInstances objectCode="movies"> <instance instanceCode="Star Wars" objectCode="movies11"> <CustomInformation> <ColumnValue name="category">Science Fiction</ ColumnValue> <ColumnValue name="code">Star Wars</ColumnValue> <ColumnValue name="cost">20000000</ColumnValue> <ColumnValue name="cost_currency">USD</ ColumnValue> <ColumnValue name="name">Star Wars</ColumnValue> <ColumnValue name="page_layout">odf.moviesFrame</ColumnValue> <ColumnValue name="partition_code">US</ ColumnValue> <ColumnValue name="us_rating">PG-13</ ColumnValue> </CustomInformation> <OBSAssocs/> </instance> </customObjectInstances> </NikuDataBus> </obj: WriteCustomObjectInstance>
Partitioning
Like standard stock objects, the read CustomObjectInstances response service provides partition view information for each custom object instance. You can write a partition view to each write CustomObjectInstances instance. In the previous XML write request example, the partition view of US is specified for the Star Wars movie instance definition.
ContentPack Service
The ContentPack service is an entry point to enable XOG communication with Studio components, such as objects, object views, NSQL queries, portlets, process definitions, report definitions, lookups, and portlet pages.
For more information, see
Classic PPM
 
Studio Development
.
Read Content Pack Objects
Like standard stock objects, the read ContentPack request service is also defined by the
nikuxog_read.xsd
schema as shown in this example. However, for the ContentPack service, the schema is unique because it includes several possible query type elements. The query elements allow you to read Studio components.
The query types are cumulative, this allows, for example, query for a page and a separate query for a portlet not on that page. 
The following query types are supported:
  • JobQuery
  • LookupQuery
  • MenuQuery
  • PageQuery
  • PartitionModelQuery
  • PortletQuery
  • ProcessQuery
  • QueryQuery
  • ViewQuery
For more information about reading the query types using ContentPack XOG, see the
nikuxog_readTypes.xsd
and
nikuxog_readQueryTypes
files. These files are stored in the xsd directory that was created when you installed the XOG client.
Example XML Read Request
This example shows ViewQuery for reading the property and list components of the custom object myObject_v1.
<obj:ReadContentPack xmlns:obj="http://www.niku.com/xog/Object"> <NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_read.xsd"> <Header version="12.0.0.5028" externalSource="NIKU"/> <ViewQuery> <Filter name="code" criteria="EQUALS">property</Filter> <Filter name="object_code" criteria="EQUALS">myObject_v1</Filter> </ViewQuery> <ViewQuery> <Filter name="code" criteria="EQUALS">list</Filter> <Filter name="object_code" criteria="EQUALS">myObject_v1</Filter> </ViewQuery> </NikuDataBus> </obj:ReadContentPack>
Read Content Pack Objects with Partitioning
You can filter on partition views from a ContentPack read request by including the <ViewQuery> filter condition attribute. To read specific partitioned views using the ContentPack XOG, you must explicitly request these partitions in a ViewQuery by including the partition_code.
Specify these items in the file:
  • object_code
    . Indicates the 
    Classic PPM
     identifier for the object.
  • partition_code
    . Indicates the 
    Classic PPM
     identifier for the partition. If the partition_code is not specified, views for all partitions are exported.
Example XML Read Request with Partitioning
This read ContentPack request specifies the ABC partition for the custom object myObject_v1.
<obj:ReadContentPack xmlns:obj="http://www.niku.com/xog/Object"> <NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_read.xsd"> <Header version="12.0.0.5028" externalSource="NIKU"> <!-- the contentType is used to determine which filter goes where --> <args contentType="job_definition" name="order_by_1" value="code"/> <args contentType="menu" name="order_by_1" value="code"/> <args contentType="view" name="order_by_1" value="code"/> <args contentType="process" name="order_by_1" value="code"/> <args contentType="object" name="order_by_1" value="code"/> </Header> <ViewQuery> <Filter name="code" criteria="EQUALS">property</Filter> <Filter name="object_code" criteria="EQUALS">myObject_v1</Filter> <Filter name="partition_code" criteria="EQUALS">ABC</Filter> </ViewQuery> <ViewQuery> <Filter name="code" criteria="EQUALS">list</Filter> <Filter name="object_code" criteria="EQUALS">myObject_v1</Filter> <Filter name="partition_code" criteria="EQUALS">ABC</Filter> </ViewQuery> <ObjectQuery> <Filter name="object_code" criteria="EQUALS">myObject_v1</Filter> </ObjectQuery> </NikuDataBus> </obj:ReadContentPack>
Export Content Types Without Dependencies
You can use these arguments,
singleContentType
and
no_dependencies,
to export individual content types and to limit the amount of data that is exported for each type. These arguments should be used only for small, incremental updates to content.
Use care when applying these arguments. The user performing the export must have a thorough understanding of content data on the source and target systems.
  • singleContentType
    . Exports a specific content type. Specify the singleContentType argument in the XML read file. This is the format for the argument in the XML read file:
    <args name="singleContentType" value="content type">
    In this argument,
    content type
    can be any of these supported content types:
    • Job Definitions
    • Lookups
    • Menu Manager
    • Objects
    • Portlet Pages
    • Portlets
    • Processes
    • Queries
  • No_dependencies
    . Limits the amount of data that is exported for a specific content type. This is the format for the argument in the XML read file:
    <args name=“no_dependencies” value=“true/false”/>
    In this argument,
    true
    exports incremental changes for a content type without dependencies. By default, the
    no_dependencies
    flag is false, which means any dependencies that exist for the value that is specified in the singleContentType argument are exported if the value is not specified.
The following table shows the content types that are exported when the no_dependencies argument is set to true.
Content Type
Attributes
job_definition
active, executable, isHidden, jobDefinitionCode, jobType, logEnabled, outputEnabled, runConcurrent, source, description, name, attributes related to parameter like code, dataType, defaultValue, order, readOnly, required, widgetType, attributes related to OBSAssocs like complete, Security
lookup
code, hiddenAttributename, sortStype, source, status, description, name, sortorder, attributes related to partition
menu
code, source, description, name, link, section
object
code, source, description, name, displayMapping, parentObjectCode
page [portlet page]
tabbedPage, code, customizable, layout, linkable, objectypes, personalizable, source, space, template, description, name, tab, OBSAssocs, Parameter, dataref, dataSource, paramCode
portlet
allowConfigure, allowConfigureLabel, category, code, colorItem, dataProviderId, dataProvideerPartitionId, dataProviderType, datapointLabels,
firstSliceAngle, forceFilter, link, mouseoverLbels, objectType, seriesDimension, showLegend, showTitle, size, source, type, name, decimalPlaces
Note
: Attributes can vary depending on type of portlet.
process
code, endStep, allowOneRunningInstance, source, startOption, startStep, description, name, rightCode, username, manualStart, objectType, partitionCode, partitionModeCode, type, isMileStone, sequenceNo, attributes related to Notifications, Operations, TransactionRestrictions
query
category, code, description, name, attributes related to nsql like dbId, dbVendor, attributes for link like action, code
Example: XML Read File for Exporting a Portlet Without Dependencies
This example shows an XML read file where portlet data without any dependency data is requested. 
<?xml version="1.0" encoding="UTF-8" ?> - <NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_read.xsd"> - <Header version="12.0.0.5028" action="read" objectType="contentPack" externalSource="NIKU"> <!-- Provide following argument with singlecontenttype to retrieve only portlet. --> <args name="singleContentType" value="portlet" /> <!-- May specify following OPTIONAL argument no_dependencies to exclude dependent content. --> <args name="no_dependencies" value="true" /> </Header> - <PortletQuery> <Filter name="code" criteria="EQUALS">balance</Filter> </PortletQuery> </NikuDataBus>
Export Portlet Data from Studio to an XML File
To facilitate the export of portlets, you can export this content type from Studio. The
Portlets
list page has an Export button that lets you export basic data on the portlets as individual XML files. The output XML files, which are packaged into a zip file, contain basic information with no dependencies.
Autonumbering and Custom Attributes
The flag
overrideAutoNumbering
is an argument that is defined in the XOG header that determines whether the source XOG content overrides autonumbering in the target content. This flag is available for the custom attributes of custom objects. These rules apply:
  • If the flag is set to TRUE, the XOG content from the source is applied to the target.
  • If the flag is set to FALSE, the autonumbering scheme that is defined on the target is applied.
  • The flag is specified in the XOG import file.
By default, OverrideAutoNumbering is set to TRUE.
The following example shows the overrideAutoNumbering argument in the header:
<Header action="write" externalSource="NIKU" objectType="customObjectInstance" version="14.3.0"> <args name="overrideAutoNumbering" value="true"/> </Header>
This section describes how to set up XOG for custom object instances (both master and sub-objects) with autonumbering true and false. For the following scenarios, we have created a custom master object with id "custommaster" and a custom sub-object with id "customsub".
Scenario 1: Custom Master Object with 
overrideAutoNumbering Set to 'true' (Auto-numbering disabled)
The following XML code snippet is used in a XOG write file for adding a custom master object instance with autonumbering OFF.
<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_customObjectInstance.xsd">
 <Header action="write" externalSource="NIKU" objectType="customObjectInstance" version="13.2.0.472">
   <!-- when you are overriding autonumbering, following header is optional as the default settings for 'overrideAutoNumbering' is anyways 'true' -->
     <args name="overrideAutoNumbering" value="true"/>
     </Header>
           <customObjectInstances objectCode="custommaster">
           <!-- leave instanceCode as "" -->
           <instance instanceCode="" objectCode="custommaster">
           <CustomInformation>
           <!-- when you are overriding autonumbering, you have to provide a code here -->
           <ColumnValue name="code">manual</ColumnValue>
           <ColumnValue name="name">cm5</ColumnValue>
           <ColumnValue name="odf_period_end"/>
           <ColumnValue name="odf_period_start"/>
           <ColumnValue name="page_layout">odf.custommasterFrame</ColumnValue>
           <ColumnValue name="partition_code">NIKU.ROOT</ColumnValue>
           </CustomInformation>
          <OBSAssocs complete="false"/>
        <Security>
     <UserSecurity rightCode="odf_cst_custommaster_edit" userName="admin"/>
  </Security>
 </instance>
</customObjectInstances>
</NikuDataBus>
Scenario 2: Custom Master Object with 
overrideAutoNumbering Set to 'false' ( Auto-numbering  enabled)
The following XML code snippet is used in a XOG write file for adding a custom master object instance
 
(for Auto-numbering enabled)
<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_customObjectInstance.xsd">
  <Header action="write" externalSource="NIKU" objectType="customObjectInstance" version="13.2.0.472">
   <!-- when you are NOT overriding autonumbering, following header is mandatory as the default settings for 'overrideAutoNumbering' is 'true' -->
    <args name="overrideAutoNumbering" value="false"/>
     </Header>
      <customObjectInstances objectCode="custommaster">
          <!-- leave instanceCode as "" -->
         <instance instanceCode="" objectCode="custommaster">
          <CustomInformation>
           <!-- when you are NOT overriding autonumbering, you have to provide -1 as code here and system will generate an autonumbered code -->
          <ColumnValue name="code">-1</ColumnValue>
          <ColumnValue name="name">cm4</ColumnValue>
          <ColumnValue name="odf_period_end"/>
          <ColumnValue name="odf_period_start"/>
          <ColumnValue name="page_layout">odf.custommasterFrame</ColumnValue>
          <ColumnValue name="partition_code">NIKU.ROOT</ColumnValue>
          </CustomInformation>
        <OBSAssocs complete="false"/>
     <Security>
   <UserSecurity rightCode="odf_cst_custommaster_edit" userName="admin"/>
  </Security>
</instance>
</customObjectInstances>
</NikuDataBus>
Scenario 3: Custom sub object with  overrideAutoNumbering true (Auto-numbering disabled)
The following XML code snippet is used in a XOG write file for adding a custom sub-object instance (for Auto-numbering disabled)
<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_customObjectInstance.xsd">
 <Header action="write" externalSource="NIKU" objectType="customObjectInstance" version="13.2.0.472">
   <!-- when you are overriding autonumbering, following header is optional as the default settings for 'overrideAutoNumbering' is 'true' -->
     <args name="overrideAutoNumbering" value="true"/>
       </Header>
        <customObjectInstances objectCode="customsub">
          <
!-- leave instanceCode and parentInstanceCode as "" --
>
            <instance instanceCode="" objectCode="customsub" parentInstanceCode="" parentObjectCode="custommaster">
       <CustomInformation>
       <!-- when you are overriding autonumbering, you have to provide a code here -->
       <ColumnValue name="code">manual</ColumnValue>
       <ColumnValue name="name">cs15</ColumnValue>
       <ColumnValue name="odf_cncrt_parent_id">5000000</ColumnValue> <!-- this is the instanceId for the parent instance -->
       <ColumnValue name="odf_parent_id">5000000</ColumnValue> <!-- this is the instanceId for the parent instance -->
        <ColumnValue name="partition_code">NIKU.ROOT</ColumnValue>
       </CustomInformation>
         <OBSAssocs complete="false"/>
      <Security>
     <UserSecurity rightCode="odf_cst_customsub_edit" userName="admin"/>
  </Security>
</instance>
</customObjectInstances>
</NikuDataBus>
Scenario 4: Custom Sub Object with overrideAutoNumbering false (Auto-numbering enabled)
The following XML code snippet is used in a XOG write file xog write file for adding a custom sub-object instance Auto-numbering enabled
<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_customObjectInstance.xsd">
  <Header action="write" externalSource="NIKU" objectType="customObjectInstance" version="13.2.0.472">
    <!-- when you are NOT overriding autonumbering, following header is mandatory as the default settings for 'overrideAutoNumbering' is 'true' -->
     <args name="overrideAutoNumbering" value="false"/>
      </Header>
        <customObjectInstances objectCode="customsub">
          <!-- leave instanceCode and parentInstanceCode as "" -->
         <instance instanceCode="" objectCode="customsub" parentInstanceCode="" parentObjectCode="custommaster">
         <CustomInformation>
         <!-- when you are NOT overriding autonumbering, you have to provide -1 as code here and system will generate an autonumbered code -->
        <ColumnValue name="code">-1</ColumnValue>
        <ColumnValue name="name">cs14</ColumnValue>
        <ColumnValue name="odf_cncrt_parent_id">5000000</ColumnValue> <!-- this is the instanceId for the parent instance -->
        <ColumnValue name="odf_parent_id">5000000</ColumnValue> <!-- this is the instanceId for the parent instance -->
        <ColumnValue name="partition_code">NIKU.ROOT</ColumnValue>
        </CustomInformation>
       <OBSAssocs complete="false"/>
     <Security>
   <UserSecurity rightCode="odf_cst_customsub_edit" userName="admin"/>
  </Security>
 </instance>
 </customObjectInstances>
</NikuDataBus>
Import and Export Custom Fiscal Time-Varying Attributes
You can export or import custom fiscal time-varying attributes as part of the import or export of a standard or custom subobject with which the attributes are associated. When a subobject is exported, the XOG export file includes these elements:
  • Custom attributes and modified views for the subobject
  • Custom attributes and modified views for the master object
  • Referenced lookups
If a subobject includes custom fiscal time-varying attributes, the master object export file includes these additional elements:
  • Fiscal entity
  • Fiscal time period
  • Department OBS associations
Import and Export UI Themes
You can import and export UI themes through the XOG. The XOG client provides sample UI theme XML files. The import file for UI themes is
cmn_ui_themes_write.xml
. The
default
attribute on the UITheme element determines whether a UI theme that is being imported is the default theme for the system. If the
default
attribute is set to true, the theme becomes the system default theme. If you are importing multiple UI themes in one import file, only one UI theme is expected to have the
default
attribute set to true. If multiple themes in a single import have the
default
attribute set to true, the last theme processed with the attribute set to true becomes the default theme.
Sample Import File cmn_UI_themes_write.xml
This section of the
cmn_ui_themes_write.xml
shows the
default
attribute set to false. In this case, the UI theme that is being imported is not the default 
Classic PPM
 UI theme.
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (c) 2011, CA Inc. All rights reserved. --> <NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_uitheme.xsd"> <Header action="write" externalSource="NIKU" objectType="uitheme" version="13.0"/> <UIThemes> <UITheme active="true" default="false" id="sample_ui_theme"> <nls description="A sample UI Theme" languageCode="en" name="Sample UI Theme"/> <css><![CDATA[
Include New and Delete Buttons
When you are importing a new custom object, the New button and the Delete button are deselected. You cannot immediately create an instance of the object. To make the New and Delete buttons available immediately for the new object, include these two lines in the script:
<action code="[email protected]@Create"/> <action code="odf.deleteObjectInstancesConfirm"/>
Example:
<list> .... <action code="odf.testCreate"/> <action code="odf.deleteObjectInstancesConfirm"/> .... </list>
Passing XDM Custom Fields
XDM configuration changes are automatically handled by the Object API. These rules apply:
  • For the Name and Values fields, use those defined in the customFieldsMetadata.xml file.
  • For lookups, pass the lookup code and dates (in YYYY-MM-DD format).
  • For check box fields, pass 1 or 0.
Example
<CustomInformation> <ColumnValue name="CEO_NAME">ceo2</ColumnValue> <ColumnValue name="DEFAULTWEBSITE">http://www1</ColumnValue> <ColumnValue name="NUM_OF_EMPLOYEES">100</ColumnValue> <ColumnValue name="OPPORTUNITY">1</ColumnValue> </CustomInformation>