OnDemand Web Services

CRM OnDemandCRM

Siebel Web Services OnDemandGuide

Version 5(CRM OnDemand Release 10)

November 2005

Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404Copyright © 2005 Siebel Systems, Inc. All rights reserved.Printed in the United States of America

No part of this publication may be stored in a retrieval system, transmitted, or reproduced in any way, including but not limited to photocopy, photographic, magnetic, or other record, without the prior agreement and written permission of Siebel Systems, Inc.

Siebel, the Siebel logo, UAN, Universal Application Network, Siebel CRM OnDemand, and other Siebel names referenced herein are trademarks of Siebel Systems, Inc., and may be registered in certain jurisdictions.

Other product names, designations, logos, and symbols may be trademarks or registered trademarks of their respective owners.

PRODUCT MODULES AND OPTIONS. This guide contains descriptions of modules that are optional and for which you may not have purchased a license. Siebel’s Sample Database also includes data related to these optional modules. As a result, your software implementation may differ from descriptions in this guide. To find out more about the modules your organization has purchased, see your corporate purchasing agent or your Siebel sales representative.

U.S. GOVERNMENT RESTRICTED RIGHTS. Programs, Ancillary Programs and Documentation, delivered subject to the Department of Defense Federal Acquisition Regulation Supplement, are “commercial computer software” as set forth in DFARS 227.7202, Commercial Computer Software and Commercial Computer Software Documentation, and as such, any use, duplication and disclosure of the Programs, Ancillary Programs and Documentation shall be subject to the restrictions contained in the applicable Siebel license agreement. All other use, duplication and disclosure of the Programs, Ancillary Programs and Documentation by the U.S. Government shall be subject to the applicable Siebel license agreement and the restrictions contained in subsection (c) of FAR 52.227-19, Commercial Computer Software - Restricted Rights (June 1987), or FAR 52.227-14, Rights in Data—General, including Alternate III (June 1987), as applicable. Contractor/licensor is Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404.

Proprietary Information

Siebel Systems, Inc. considers information included in this documentation and in Siebel Online Help to be Confidential Information. Your access to and use of this Confidential Information are subject to the terms and conditions of: (1) the applicable Siebel Systems software license agreement, which has been executed and with which you agree to comply; and (2) the proprietary and restricted rights notices included in this documentation.

Siebel Web Services OnDemand Guide Version 5 (CRM OnDemand Release 10) 3

Contents

Siebel Web Services OnDemand Guide 1

Chapter 1: What’s New in This Release

Chapter 2: Overview of Web Services OnDemandAbout Web Services 9

OnDemand Web Services 10XML API Security 11XML API Reliability 12

Web Services and the OnDemand Objects 12About Parent-Child Relationships 14Behavior of Methods on Parent and Child Objects 15Methods Called by the OnDemand Objects 15OnDemand User Keys 15OnDemand Status Keys 16OnDemand Pick Maps 16Audit Fields 17Web Services OnDemand and Custom Fields 17

Field Types Supported by OnDemand 18Locale-Dependent Access to OnDemand 18

Chapter 3: Getting Started with Web ServicesProcess of Setting Up Web Services OnDemand 19

Establishing and Managing the XML API Session 19Logging In to the XML API Session 20Integration Requests for the XML API Session 21Logging Out of the XML API Session 21Limits for the XML API Session 22

Code Samples for Logging In and Logging Out 23Sample VB Code 24Java Code Sample 26C# Code Sample 30

Siebel Web Services OnDemand Guide Version 5 (CRM OnDemand Release 10)

Contents ■

4

Chapter 4: OnDemand Objects Exposed Through Web Services

Parent Objects 33Account 34Activity 48Campaign 54Contact 60Current User 73CustomObject1 75CustomObject2 83Dealer 91Household 93Lead 98LOV 102Opportunity 104Portfolio 113Product 117Product Category 120Service Request 122Solution 127Territory 130User 132User Group 135Vehicle 137

Child Objects 141Address 142Asset 142Audit Trail 143Competitor 143Login History 143Multiple Contact Roles 144Note 144Partner 144Quota 145Related Account 145Related Contact 145Revenue 145Team 146

Chapter 5: Web Services OnDemand API CallsAPI Calls 147

Contents ■


Delete 148Insert 149InsertOrUpdate 150QueryPage 151Update 156

Service API Calls 157GetListOfValues 158GetMapping 159SetPasswordAPI 159

Appendix A: OnDemand XML API SamplesQuery by Example Expression Samples 161

Query by Template Samples 164

Query by Children Samples 165

LOV Service Element Sample 170

Index


Contents ■

6


1 What’s New in This Release

Siebel Web Services OnDemand Guide contains new and previously released material.

What’s New in Siebel Web Services OnDemand Guide, Version 5 (CRM OnDemand Release 10)Table 1 lists new features in this version of the documentation to support Version 5 (CRM OnDemand Release 10).

Table 1. New Product Features in Siebel Web Services OnDemand Guide, Version 5 (CRM OnDemand Release 10)

Topic Description

“About Parent-Child Relationships” on page 14

The matrix table that details parent child relationships has been removed. This information is now contained in the section that details each parent service and child component.

“Methods Called by the OnDemand Objects” on page 15

The table that details the methods called by each service has been removed. This information is now contained in the section that details each parent section.

“Logging Out of the XML API Session” on page 21

Extra information about logging out of the XML API session has been added.

“Parent Objects” on page 33 Information on parent services of, child components of and methods called by each service has been included for each parent service.

“Account” on page 34 The revenue child component has been added to the account service.

“Contact” on page 60 The revenue child component has been added to the contact service.

“CustomObject1” on page 75 The CustomObject1 service is a new service that has been added for this release, and is described in this section.

“CustomObject2” on page 83 The CustomObject2 service is a new service that has been added for this release, and is described in this section.

“Dealer” on page 91 The dealer service is a new service that has been added for this release, and is described in this section.

“Service Request” on page 122 A new method, ServiceRequestDelete, has been added to the Service Request service.


What’s New in This Release ■

8

“QueryPage” on page 151 A new parameter, UseChildAnd, has been added to all QueryPage calls.

“GetMapping” on page 159 This is a new section that describes the GetMapping method.

Table 1. New Product Features in Siebel Web Services OnDemand Guide, Version 5 (CRM OnDemand Release 10)

Topic Description


2 Overview of Web Services OnDemand

This chapter provides an overview of Siebel CRM OnDemand’s support for Web services. It contains the following sections:

■ “About Web Services”

■ “Web Services and the OnDemand Objects” on page 12

■ “Field Types Supported by OnDemand” on page 18

About Web ServicesThe term Web services describes a standardized way of integrating Web-based applications over the Web. Web services allow businesses to communicate with each other and with other clients, without intimate knowledge of each other’s IT systems behind a firewall. Web services share business logic, data, and processes through a Web services API. Application developers can then add the Web services to a GUI (such as a Web page or executable program) to offer specific functionality to users.

Web Services Core TechnologiesThe Web services core technologies include:

■ Extensible Markup Language (XML): XML defines the structure and content of Web services. The OnDemand Web Services objects and methods are defined using XML.

■ Web Services Description Language (WSDL): This is an XML-formatted language that is used to describe the Web service’s capabilities, which allows applications to communicate effectively. The WSDL file is an XML file that defines the objects and methods.

■ Simple Object Access Protocol (SOAP): SOAP is used to send Web services messages. Web services messages are sent between the customer implementation of Web services and the SOAP handler on the Siebel Web Server.

For more information on Web services technologies, see http://www.w3.org/2002/ws.

Siebel OnDemand Web Services ToolkitA Siebel OnDemand Web Services Toolkit (Web Services Toolkit) is essentially composed of two core parts:

■ SOAP Handler: This handler listens for incoming SOAP messages and invokes upon the implementation (detailed below). It is also used to transfer the response back to the Web client.

■ Implementation: This is the actual implementation of the Web service that provides the core functionality. This back-end implementation of the Web service is implemented in an Enterprise Java Bean (EJB) file.


Overview of Web Services OnDemand ■ About Web Services

10

Figure 1 shows how the Web Services Toolkit interacts with the OnDemand database. The customer uses the Web Services Toolkit (WSDLs) to define the objects and methods that are contained in the OnDemand Hosted Service. The customer application communicates with OnDemand over the Internet using the secure HTTPS protocol. It invokes the Web services implementation contained in the OnDemand Hosted Service. The Web services implementation is used to create, update, delete, or modify the objects that reside in the OnDemand database.

OnDemand Web ServicesThe Web Services Toolkit is a set of APIs that companies can use to build programs to integrate with OnDemand. It provides a programmatic interface for accessing your company's Siebel CRM OnDemand information. A customer application can use the Web Services Toolkit through standard Web services development tools such as those provided by IBM's WebSphere, Microsoft's .NET, and BEA's WebLogic. It exposes XML operations that interact with the components of Siebel CRM OnDemand's online service.

Some common examples of client integrations include the following:

■ Integrations of CRM and back-office applications. You can retrieve real-time sales, marketing, and service information from Siebel CRM OnDemand and use it in financial and other back-office applications. For example, you can retrieve information about recently closed opportunities through the Web services interface and insert this information into an order entry system that has a Web services user interface. In addition, you can store information from back-office applications in Siebel CRM OnDemand for instant access by end users, visible in custom fields on any Siebel CRM OnDemand page.

Figure 1. How Web Services Communicate with OnDemand

Overview of Web Services OnDemand ■ About Web Services


■ Web-based portal applications. You can create customized Web-based applications using Active Server Pages (ASPs), Java Server Pages (JSPs), or similar Web technology that accesses Siebel CRM OnDemand through the Web services interface. For example, a Siebel CRM OnDemand customer can deploy a customized Web form on its corporate Web site, allowing visitors to enter requests for more information. The application creates new lead records in Siebel CRM OnDemand for these requests through the Web services interface. Another Web page can allow visitors to browse through solutions to common problems stored in Siebel CRM OnDemand and retrieved in real time through the Web services interface.

■ Custom add-on modules. Customers can also extend Siebel CRM OnDemand functionality. For example, a company may create a custom add-on module to streamline its unique quote creation process, or a company may create additional utilities to perform mass data cleanup operations. These modules access data in Siebel CRM OnDemand directly through the Web services interface. OnDemand administrators and end users can run these modules while concurrently accessing the Siebel CRM OnDemand user interface.

XML API SecurityThe Siebel CRM OnDemand Web Services Integration framework includes the following security features:

■ All communications are encrypted with SSL for security (minimum 128-bit).

■ Access is session-based, requiring authorization with a valid Siebel CRM OnDemand user name and password.

■ Inactive sessions are closed automatically after a period of inactivity.

■ The same data visibility and access capabilities that apply to users in the Siebel CRM OnDemand hosted service are applied to users connected through the Web services interface. Data visibility and access are restricted by the role that your company assigns. Permissions are checked for every data access.

■ A full audit trail of Web services activity is available through Siebel CRM OnDemand's Administration pages. These pages display both current and historical usage statistics.

■ A number of other proprietary solutions protect the system against malicious use of the Web services interface. These solutions are constantly reviewed and improved as new technologies and techniques become available.

The system creates a session with a standard HTTPS request to establish a connection with Siebel CRM OnDemand through the Web services interface. A client creates a new session with the Login operation and closes it with the Logoff operation. When a session is created, the system provides an encrypted session identifier to the client. Security is maintained by the client including the session identifier with each request during that session.


Overview of Web Services OnDemand ■ Web Services and the OnDemand Objects

12

XML API ReliabilityAll server components of Siebel CRM OnDemand, including those responsible for the Web services interface, incorporate load balancing and other high-availability mechanisms. These mechanisms prevent the service from being interrupted by server or network infrastructure failure.

Web Services and the OnDemand ObjectsWeb services are a set of standards-based technologies that allow heterogeneous applications to integrate with Siebel OnDemand. They provide the ability to publish, find, and invoke upon the core Siebel OnDemand objects across the Web from any client application language. This makes the process of using OnDemand objects very easy for those who want to use them.

The OnDemand objects provide a basis for customers to perform integration with OnDemand based on SOAP technology. Table 2 details the OnDemand parent and child objects that are available through OnDemand Web Services. For more information about parent-child relationships, see “About Parent-Child Relationships” on page 14.

Table 2. OnDemand Objects—Parent Object Denoted by P

Object Description

“Account” on page 34 (P)

Stores information on companies with which your organization has a relationship, that is, customers, prospects, partners, and competitors.

“Activity” on page 48 (P)

Stores information on an activity that a user must carry out — for example, a call-back activity for an account. When an activity is created, the end user must set the display field explicitly to Task or Appointment.

“Campaign” on page 54 (P)

Provides a mechanism for marketing products and services to customers and prospects.

“Contact” on page 60 (P)

Stores information on individuals with whom your organization has a relationship.

“Current User” on page 73 (P)

Stores information on the user who is currently logged in to the OnDemand system.

“CustomObject1” on page 75

Exposes the functionality of the CustomObject1 OnDemand object to external applications.

“CustomObject2” on page 83

Exposes the functionality of the CustomObject2 OnDemand object to external applications.

“Dealer” on page 91 Stores information about dealerships in the automotive industry.

“Household” on page 93

Stores financial details about a group of contacts that live in the same household.

“Lead” on page 98 (P) Stores information on a company or individual with whom an opportunity is created and worked.



“LOV” on page 102 (P) Stores information on a list of values for a specified picklist.

“Opportunity” on page 104 (P)

Stores information on a potential revenue-generating event and is another type of information that you can use to manage accounts.

“Portfolio” on page 113 (P)

Stores information on the collection of financial services that you may provide to an account.

“Product” on page 117 (P)

Stores information on a product or service that your company provides to its customers.

“Product Category” on page 120 (P)

Stores information on groups of products that are related to each other.

“Service Request” on page 122 (P)

Stores information on requests made by customers of your organization.

“Solution” on page 127 (P)

Stores information on solutions to customer problems or service requests.

“Territory” on page 130 (P)

Stores information about the territory for which a user is responsible.

“User” on page 132 (P) Stores information on all the users of the system.

“User Group” on page 135 (P)

Stores information about groups of users.

“Vehicle” on page 137 (P)

Stores information on vehicles that may be sold to accounts or contacts.

“Address” on page 142 (C)

Stores information on the different addresses that are associated with accounts and contacts.

“Asset” on page 142 (C)

Stores information on the assets held by your accounts — for example, the products that an account has purchased.

“Audit Trail” on page 143 (C)

Stores information about how a service request object is modified from the moment that it created until a solution for the service request has been found.

“Competitor” on page 143 (C)

Stores information on the competitor.

“Login History” on page 143 (C)

Stores information about currently logged in user such as the amount of times that the user has logged in, and the dates and times on which the current user logged in.

“Multiple Contact Roles” on page 144 (C)

Stores information on the different roles that a contact can hold within an account.

“Note” on page 144 (C) Stores extra information (as a note) on a parent object.

“Partner” on page 144 (C)

Stores information on the partner.


Object Description



14

About Parent-Child RelationshipsMany of the OnDemand objects interact with each other through parent-child relationships. A parent object refers to the main or base object of interest and the child object refers to objects that are related to the parent in some way—for example, if the child object is contained in the parent, or if the child object has records that refer to the parent object.

These parent-child relationships can be one-to-many or many-to-many. For example, a lead may be associated with a particular account, but an account may have many leads associated with it. In this case, the relationship between the account and its leads may be thought of as a one-to-many parent-child relationship.

Other relationships may be many-to-many, meaning that many children may be associated with many parents. For example, a contact may be associated with several opportunities, or an opportunity may have several contacts associated with it. In this case, the relationship between contacts and their opportunities may be thought of as a many-to-many parent-child relationship. The parent-child relationship between contacts and opportunities may be treated with either the opportunity as the parent with contacts as children, or with the contact as the parent and the opportunities as children.

“Quota” on page 145 (C)

Stores information about the sales targets of, and sales made by the current user.

“Revenue” on page 145 (C)

Stores information about the product revenue for a particular opportunity.

“Related Account” on page 145 (C)

Stores information on an account that has a relationship with the parent account in question.

“Related Contact” on page 145 (C)

Stores information on an contact that has a relationship with the parent contact in question.

“Team” on page 146 (C)

Stores information on the team that is assigned to a particular account or contact.


Object Description



Behavior of Methods on Parent and Child ObjectsDepending on whether an object is a parent or child object, Web services methods may act in different ways on the object in question. Table 3 outlines how methods may act upon parent and child objects to create or update an object instance.

Methods Called by the OnDemand ObjectsThere are a number of methods that may be called on the OnDemand objects. These methods are detailed in Chapter 5, “Web Services OnDemand API Calls.” For information about the methods called by each service, see the relevant section in Chapter 4, “OnDemand Objects Exposed Through Web Services.”

OnDemand User KeysUser keys are subsets or groups of fields in an object table that can be used to uniquely identify a record. A particular table or object may have any number of User Key subsets defined for records in that table. The most basic subset of fields that identifies a record is the single field RowId (or primary key field). Every record in the database has at least three of the following independent user keys: RowId or primary key, IntegrationId, and ExternalSystemId. In addition, there are various field combinations for different objects that can also be used to define uniqueness.

It is only possible to query for a particular record or update a particular record in a table, if the values of all the fields in any user key subset is known. Any valid group of user keys can uniquely identify the record that a user wants to query or update. For example, the RowId, IntegrationId, or ExternalSystemId field of an object instance uniquely identifies a record, and the object table can be queried using that field as the user key.

Table 3. Effect of Methods on Parent and Child Objects

Method New Parent New ChildExisting Parent

Existing Child

Missing Child

Delete Error Error Removes instance

Error Error

Insert New parent instance

New child instance

Error Use child instance

Not applicable

InsertOrUpdate New parent New child Update parent

Update child Child is unchanged

Update Error New child Update parent

Update child Child is removed



16

In some instances, the RowId, IntegrationId, or ExternalSystemId of a record may not be known, but its name, description, or other unique identification information may be known. In these cases, if a user key for a particular record is defined to be a subset of fields whose values are known, the record can be successfully updated using this user key. For example, for a Note child object, the Subject and Description fields can be used in conjunction with each other to determine whether the record is unique or not. Such a combination is not guaranteed to provide complete uniqueness, but it may be used to query for uniqueness.

Generally, a subset of the record’s fields are used as a user key. However, one field on its own may also act as a user key, depending on whether the field can identify the record as unique. Each user key group can be used independently to identify a record. The user keys for each object are detailed for each object in Chapter 4, “OnDemand Objects Exposed Through Web Services.”

OnDemand Status KeysAn OnDemand status key is a field or a number of fields that is returned following an operation on an OnDemand object. The status key of objects contained through the Web services API contains all User Key and Audit fields in addition to some other fields that are identified as status keys for the object. The status keys for the OnDemand objects are outlined in “Parent Objects” on page 33.

OnDemand Pick MapsAn OnDemand pick map allows you to set a foreign key for an object using a different object. For example, when updating an account, you may want to set the owner of the account to a specific user. If the UserId of the user is known it can be populated in the OwnerId field. However, if only the alias of the user is known it can be populated in the Owner field. When OnDemand recognizes that the Owner field has been set, it will automatically set the OwnerId to the UserId for the user. Pick maps may be used by a number of OnDemand objects to update foreign key references in this way.

A list of pick map fields, and the fields that they map to, are detailed in “Parent Objects” on page 33 for each object.



Audit FieldsAudit fields on an object provide information about who created an instance of the object, when it was created, who has updated an instance of the object, and when it was updated. All objects, both parent and child level, exposed by the Web services API contain the read-only Audit fields contained in Table 4.

Web Services OnDemand and Custom FieldsSiebel CRM OnDemand allows company administrators to create custom fields that capture information specific to the company’s needs. Web Services OnDemand allows customers to interact with the data stored in these custom fields. Each custom field has an associated integration tag that is used by Web services and Web links to reference data in custom fields. This allows administrators to change the display name of a field without the need to make modifications to the existing Web services integration.

To view or modify integration tag information for an object

1 Navigate to the Field Setup Administration screen for the required object.

2 Click Advanced.

The integration tag information is displayed for you to view or modify.

To generate a WSDL file that is specific to your company’s customization

1 Navigate to the Web Services Administration screen.

Table 4. Audit Fields for the OnDemand Objects

Field Name Description

CreatedBy This field is a combination of the full name of the person that created this instance of the object, and the date on which the instance was created. This information is contained within the field in the following format:

“<Creator Full Name>, <CreatedDate>”

CreatedById The Row ID of the user that created the record.

CreatedDate The DateTime stamp of when the record was created.

ModifiedBy This field is a combination of the full name of the person that modified this instance of the object, and the date on which the instance was modified. This information is contained within the field in the following format:

“<Modified By Full Name>, <ModifiedDate>”

ModifiedById The Row ID of the user that last modified the record.

ModifiedDate The DateTime stamp of when the record was last modified.


Overview of Web Services OnDemand ■ Field Types Supported by OnDemand

18

2 Select the required object, and click Download.

An object’s WSDL that is specific to your company’s customization is downloaded.

Field Types Supported by OnDemandAll fields in Web services OnDemand are transmitted and received as strings. It is the client’s responsibility to transform these to and from the required data type in any application. The proper type can usually be determined from the name, purpose, or application of the field. There is no dynamic method for determining field types. Clues about a field’s type can be derived from its name as follows:

■ A name ending in the suffix Id is usually a key field such as primary key, foreign key, or user key Id. It can usually be treated as a unique text string.

■ Fields with names containing Date or Time, such as LastUpdated, DueDate, StartTime, or EndTime may be date fields. The format for these fields is determined by the user’s online preferences settings.

■ Phone number fields can be treated as numeric phone numbers or as plain text.

■ Other numeric fields such as currency, size, revenue, or probability can be treated as integer, floating point, or text fields depending on the application.

■ Boolean fields have value Y for true or N for false.

■ Most other fields can be treated as ordinary text.

Locale-Dependent Access to OnDemandSiebel OnDemand Web Services does not provide any specialized localization interfaces. Siebel CRM OnDemand supports full localization, so that the data created through Web services will be localized for end users. The localized fields in the Web services interfaces follow the formats outlined in the sections that follow.

Date and Time FieldsDate and time fields in OnDemand are in the following format:

MM/DD/YYYY hh:mm:ss

Number and Currency FieldsNumber and currency fields in OnDemand are in raw number format. In other words, number and currency fields hold only digits with no currency symbols, decimal separators, or other numeric separators.


3 Getting Started with Web Services

This chapter provides an overview of how to get started with Siebel CRM OnDemand Web Services and contains the following sections:

■ “Process of Setting Up Web Services OnDemand” on page 19

■ “Establishing and Managing the XML API Session” on page 19

■ “Code Samples for Logging In and Logging Out” on page 23

Process of Setting Up Web Services OnDemand A customer who wants to access data in Siebel CRM OnDemand from a Web services-enabled client must perform the following tasks:

1 Request Web Services Integration. For security reasons, this capability is not automatically enabled for OnDemand customers. On request, a Siebel CRM OnDemand Customer Care representative enables the Web Services OnDemand Integration capability for your company.

2 Download WSDL files. The customer's designated OnDemand Administrator accesses the Web Services Administration page in Siebel CRM OnDemand. The Administrator downloads Web Service Description Language (WSDL) files that have been published for the desired Siebel CRM OnDemand entities.

3 Incorporate WSDL files. The company incorporates the WSDL files into its Web services development environment—for example, by generating Java or C# (C Sharp) proxy classes.

4 Establishing and Managing the XML API Session. A Web services-enabled client, including a client application written in any language that interacts with the Web services framework, establishes a secure session with Siebel CRM OnDemand. Throughout this session, the client interacts with the published OnDemand Web Service entities to perform data retrieval, modification, creation, and deletion operations. OnDemand and the client format requests and resulting data as standard XML/SOAP messages. For more information, see “Establishing and Managing the XML API Session” on page 19.

Establishing and Managing the XML API SessionThe Web Service API for OnDemand integration is session-based. It has the following features:

■ Clients must make explicit login and logout calls in their code to manage the session.

■ The login step returns an HTTP cookie that must be used for making additional requests.


Getting Started with Web Services ■ Establishing and Managing the XML API Session

20

■ A session remains active until the user explicitly logs off or until the session times out.

Web services session management service is HTTP-based. Session management in Siebel CRM OnDemand is based on a session ID, JSESSIONID, contained in HTTP Session Cookies. The session ID is critical to successful session generation and maintenance of a SOAP transaction. OnDemand Web Services enable session management by first creating a session using the login call, which is then referenced in any subsequent SOAP operations.

In a Siebel SOAP session, the session ID may be referenced in one of these two ways (after it has been created in a login request):

■ It may be attached as a parameter to the URL request line. When a session ID is present in the URL line, it is identified by the string jsessionid in lowercase, followed by the exact session ID, which is coded using URL syntax.

NOTE: This is the recommended approach to referencing the session ID.

■ It may be part of the cookie header line. When a session ID is referenced as a cookie, a cookie header line must appear in the SOAP request with the name JSESSIONID=. In this case, the session ID appears in uppercase, and the value of the cookie is exactly the same as the session ID received from the login request.

SOAP operations will not work if a Siebel Session ID is not present in one of these ways.

When a login request is made, the session ID will be returned as a cookie in the response to the request. The client is responsible for extracting this session ID and using it throughout the session. If the session times out for any reason, the error returned will say the session is not valid and the client must then request a new session. In this case no explicit logoff is required.

The logoff operation is considered one of the operations for a session, so the session ID must be present in the logoff request. However, only the cookie version is accepted in the logoff request.

The OnDemand Web Service interface supports the following three types of functions:

■ “Logging In to the XML API Session”

■ “Integration Requests for the XML API Session” on page 21

■ “Logging Out of the XML API Session” on page 21

All requests must use SSL (HTTPS).

Logging In to the XML API SessionThe Login request is an HTTPS request to instantiate a session and obtain a session ID. A client invokes login by sending an HTTP GET to a URL like the following:

https://secure.crmondemand.com/Services/Integration?command=login

NOTE: The term login is case sensitive. The protocol https indicates the use of the SSL protocol.

Login input. The input to Login is provided in the URL parameters and the HTTP headers, as follows:

■ The only URL parameter to be set is command. This parameter value is login.



■ Two HTTP headers, UserName and Password, must be set with the appropriate values for your system. For example:

UserName: [email protected]: mypass

Login output. Login returns the following items:

■ A session cookie, jsessionid. The client must use this cookie when submitting subsequent requests, including logoff requests.

■ A status code of 200, if the session does not encounter any errors. This indicates that the request succeeded.

Integration Requests for the XML API SessionAn integration request is an HTTPS request to invoke a Web service. An integration request is made by an HTTP POST to a URL like the following:

https://secure.crmondemand.com/Services/Integration/<EntityName>

where <EntityName> is the name of the relevant OnDemand entity. The system determines this OnDemand entity from the contents of the SOAP request.

Integration request input. The jsessionid returned to the client during login must be included with the request. The request must contain the jsessionid either as a cookie or as a URL parameter, as follows:

https://secure.crmondemand.com/Services/Integration/<EntityName>; jsessionid=xyZ12489w3482413

The Web service input is provided as a SOAP command in the body of the HTTP POST request.

Integration request output. The properties returned by the server populate the response headers and the response body. The following table shows the top-level properties that specify key properties of the HTTP response.

Logging Out of the XML API SessionA client logs off by sending an HTTP POST or HTTP GET to a URL. For example:

https://secure.crmondemand.com/Services/Integration?command=logoff;

NOTE: Logoff is case sensitive.

Property Comments

HttpStatus Status code returned in the response. If no value is provided, the response is given the value 200 (indicating success).

Content-Type Content type returned in the response. If no value is provided, the response is given the value text/xml.



22

Logoff input. The jsessionid returned to the client during login must be included with the request as a cookie with the same name. There are no other URL parameters or HTTP headers, and there is no HTTP body. The jsessionid returned to the client during login must be included with the request. The request must contain the JSESSIONID as a cookie. It may not be passed in as a URL parameter.

Logoff output. Logoff has no output. If the session does not encounter any errors, the status code of the response is 200. This indicates that the request succeeded.

Additional Logoff The jsessionid can be included in the URL instead of a cookie if the user wants. The following URL is what the user would use, where XXXX is the jsessionid.

https://secure.crmondemand.com/Services/Integration;jsessionid=XXXX?command=logoff

Limits for the XML API SessionThe Siebel CRM OnDemand’s Web Services interface resources can be shared by multiple organizations. Siebel CRM OnDemand provides a limiting infrastructure to make sure that some users do not consume a disproportionate share of those resources. These limiters constrain customer organizations’ use of server-side resources to equitably share available resources among users and to minimize the possibility of denial-of-service incidents.

Number of Sessions LimitUnder some circumstances, a server may be flooded with concurrent logons. Siebel CRM OnDemand provides session limiters that constrain the number of sessions an organization can have open at any given time. This upper limit on the number of sessions applies to all open Web services sessions.

The upper limit on the number of open sessions per organization is based on the number of licensed users within an organization. The system applies the following formula: If X represents the number of users in an organization, then the organization's session quota is 2X + 10.

If traffic reaches the maximum number of permitted sessions, the following error message is provided as a response to subsequent attempts to establish a session:

The maximum number of allowed simultaneous sessions has been exceeded.

This means that an end user will not be able to log on until some other sessions have ended.

Request Rate LimitAll integration requests (data exchange requests) in a session are subject to rate limiting. Rate limiting is implemented for the following reasons:

■ A user may perform long-running operations on the server that result in complex and long-running queries on the database.

■ A user may perform constant operations on the server that constantly use resources.

Getting Started with Web Services ■ Code Samples for Logging In and Logging Out


Rate limiting can alleviate the previous problems to some extent. OnDemand applies a restriction to each session to limit the number of requests per second that clients can make. The rate limit is set to twenty requests per second.

If the rate limit is exceeded, the following error message is provided to subsequent SOAP requests:

The maximum rate of requests was exceeded. Please try again in <waitTime> ms.

Request Size LimitThe upper limit on the size of any incoming HTTP request is 5 MB. If the request size is exceeded, the following error message is provided to subsequent SOAP requests:

Request exceeded the size limit of 5 MB.

Session TimeoutsWeb services sessions will time out after 5 minutes if there is no activity on the session.

Maximum Records ReturnedFor return messages the maximum number of records returned for each query is limited to 100. If the requested records exceed this limit, an error of the following type is returned:

PageSize method argument cannot be greater than 100, specified by the server parameter ‘MaximumPageSize’.

A response will never return more than the specified number of records for a parent object in a request.

Maximum Objects in a Web Services RequestThe maximum number of objects that can be sent in a single SOAP request is 20.

Code Samples for Logging In and Logging OutThe following code samples illustrate how to login and logoff using VB, Java, and C#.NET code. These samples are somewhat distinct from SOAP and are specific to Siebel CRM OnDemand Web Services. For clarity and simplicity, the following samples do not include error detection and handling. The code samples are detailed in the following sections:

■ “Sample VB Code” on page 24

■ “Java Code Sample” on page 26

■ “C# Code Sample” on page 30



24

Sample VB CodeThe following sample is compatible with Visual Studio, Visual Basic 6.0.

' Declarations used to perform http internet communications from Visual Basic.

Declare Function InternetOpen Lib "WININET.DLL" Alias "InternetOpenA" ( _

ByVal lpszAgent As String, _

ByVal dwAccessType As Long, _

ByVal lpszProxyName As String, _

ByVal lpszProxyBypass As String, _

ByVal dwFlags As Long) As Long

Declare Function InternetConnect Lib "WININET.DLL" Alias "InternetConnectA" ( _

ByVal hInternetSession As Long, _

ByVal lpszServerName As String, _

ByVal nServerPort As Integer, _

ByVal lpszUserName As String, _

ByVal lpszPassword As String, _

ByVal dwService As Long, _

ByVal dwFlags As Long, _

ByVal dwContext As Long) As Long

Declare Function HttpSendRequest Lib "WININET.DLL" Alias "HttpSendRequestA" ( _

ByVal hHttpRequest As Long, _

ByVal lpszHeaders As String, _

ByVal dwHeadersLength As Long, _

ByVal lpOptional As String, _

ByVal dwOptionalLength As Long) As Integer

Declare Function InternetReadFile Lib "WININET.DLL" ( _

ByVal hFile As Long, _

ByRef lpBuffer As Any, _

ByVal dwNumberOfBytesToRead As Long, _

ByRef lpNumberOfBytesRead As Long) As Integer

Declare Function InternetCloseHandle Lib "WININET.DLL" ( _



ByVal hInternet As Long) As Boolean

' Adds one or more HTTP request headers to the HTTP request handle.

Declare Function HttpAddRequestHeaders Lib "WININET.DLL" Alias pAddRequestHeadersA" ( _


ByVal sHeaders As String, _

ByVal lHeadersLength As Long, _

ByVal lModifiers As Long) As Integer

Declare Function HttpQueryInfo Lib "WININET.DLL" Alias "HttpQueryInfoA" ( _


ByVal lInfoLevel As Long, _

ByRef sBuffer As Any, _

ByRef lBufferLength As Long, _

ByRef lIndex As Long) As Integer

' Define a function or sub to contain the login steps as defined here.

Dim netHeaders As String * 1024

Dim headerSize as long

' Open the internet connection.

m_hInternet = InternetOpen("ApplicationName", 0, vbNullString, vbNullString, 0)

m_hConnect = InternetConnect(m_hInternet, server, 443, sProxyUser, sProxyPwd, 3, 0, 0)

m_hRequest = HttpOpenRequest(m_hConnect, "GET", "/Services/Integration?command=login", "HTTP/1.1", vbNullString, vbNullString, &H84A83000, 0)

sHeaders = "Accept-Language: en" & vbCrLf & _"Connection: Keep-Alive" & vbCrLf & _

"UserName: [email protected]" & vbCrLf & _

"Password: userpassword"

result = HttpAddRequestHeaders(m_hRequest, sHeaders, Len(sHeaders), &HA0000000) ' Add headers

result = HttpSendRequest(m_hRequest, vbNullString, 0, vbNullString, 0)

headerSize = Len(netHeaders)

result = HttpQueryInfo(m_hRequest, &H16, ByVal netHeaders, headerSize, 0)

' Now parse netHeaders for header named JSESSIONID.



26

' This will be the value to use for the rest of the session.

' Then to Logoff, do the following:

m_hRequest = HttpOpenRequest(m_hConnect, "GET", ")/Services/Integration?command=logoff", "HTTP/1.1", vbNullString, vbNullString, &H84A83000, 0)

sHeaders = "Accept-Language: en" & vbCrLf & _

"Connection: Keep-Alive" & vbCrLf & _

"Cookie: JSESSIONID=abc123:-1"

result = HttpAddRequestHeaders(m_hRequest, sHeaders, Len(sHeaders), &HA0000000) ' Add headers

result = HttpSendRequest(m_hRequest, vbNullString, 0, vbNullString, 0)

Java Code SampleThe following is a code sample for logging in and logging off using Java:

/*

* log on to a web services session at the passed in service provider location using * the passed in credentials. return a session id string that can be used in later

* communication with the service provider in the event of a successful logon

* @param wsLocation - the location of the web services provider

* @param userName - OnDemand user name (email address) of the user we are logging * in as

* @param password - password that corresponds to the userName parameter

* @return FAIL if the logon failed, session id string otherwise

*

*/

private static String logon(String wsLocation, String userName, String password)

{

String sessionString = FAIL;

try

{

// create an HTTPS connection to the OnDemand webservices

URL wsURL = new URL(wsLocation + "?command=login");



HttpURLConnection wsConnection = (HttpURLConnection)wsURL.openConnection();

// we don't want any caching to occur

wsConnection.setUseCaches(false);

// we want to send data to the server

// wsConnection.setDoOutput(true);

// set some http headers to indicate the username and password we are using to logon

wsConnection.setRequestProperty("UserName", userName);

wsConnection.setRequestProperty("Password", password);

wsConnection.setRequestMethod("GET");

// see if we got a successful response

if (wsConnection.getResponseCode() == HttpURLConnection.HTTP_OK)

{

// get the session id from the cookie setting

sessionString = getCookieFromHeaders(wsConnection);

setSessionIdFromCookie(sessionString);

}

}

catch (Exception e)

{

System.out.println("Logon Exception generated :: " + e);

}

return sessionString;

}

/*



28

* log off an existing web services session, using the sessionCookie information

* to indicate to the server which session we are logging off of

* @param wsLocation - location of web services provider

* @param sessCookie - cookie string that indicates our sessionId with the WS provider

*

*/

private static void logoff(String wsLocation, String sessionCookie)

{

try

{

// create an HTTPS connection to the OnDemand webservices

URL wsURL = new URL(wsLocation + "?command=logoff");

HttpURLConnection wsConnection = (HttpURLConnection)wsURL.openConnection();

// we don't want any caching to occur

wsConnection.setUseCaches(false);

// let it know which session we're logging off of

wsConnection.setRequestProperty("Cookie", sessionCookie);

wsConnection.setRequestMethod("GET");

// see if we got a successful response

if (wsConnection.getResponseCode() == HttpURLConnection.HTTP_OK)

{

// if you care that a logoff was successful, do that code here

// showResponseHttpHeaders(wsConnection);

}

}

catch (Exception e)

{



System.out.println("Logoff Exception generated :: " + e);

}

}

/** given a successful logon response, extract the session cookie information

* from the response HTTP headers

*

* @param wsConnection successfully connected connection to OnDemand web services

* @return the session cookie string from the OnDemand WS session or FAIL if not found*

*/

private static String getCookieFromHeaders(HttpURLConnection wsConnection)

{

// debug code - display all the returned headers

String headerName;

String headerValue = FAIL;

for (int i=0; ; i++)

{

headerName = wsConnection.getHeaderFieldKey(i);

if (headerName != null && headerName.equals("Set-Cookie"))

{

// found the Set-Cookie header (code assumes only one cookie is being set)

headerValue = wsConnection.getHeaderField(i);

break;

}

}

// return the header value (FAIL string for not found)

return headerValue;

}



30

C# Code SampleThe following is a code sample for logging in and logging off using C# (C Sharp):

using System;

using System.Net;

using System.IO;

namespace WebServiceHandler

{

public class ManageSession

{

public static string SessionID = "";

public static String Login(String loginUrlString, String userName, String password, StringBuilder output)

{

try

{

// create a http request and set the headers for authentication

HttpWebRequest myRequest = (HttpWebRequest)WebRequest.Create(loginUrlString);

HttpWebResponse myResponse;

myRequest.Method = "GET";

myRequest.Headers["UserName"] = userName;

myRequest.Headers["Password"] = password;

// Return the response.

myResponse = (HttpWebResponse)myRequest.GetResponse();

Stream sr = myResponse.GetResponseStream();



// retrieve session id

char[] sep = { ';' };

String[] headers = myResponse.Headers["Set-Cookie"].Split(sep);

for (int i=0; i <= headers.Length-1; i++)

{

if (headers[i].StartsWith("JSESSIONID"))

{

sep[0] = '=';

SessionID = headers[i].Split(sep)[1];

break;

}

}

sr.Close();

myResponse.Close();

}

catch (WebException webException)

{

}

catch (Exception e)

{

}

return SessionID;

}

public static void Logoff()

{

String logoffUrlString = serverName + "/Services/Integration?command=logoff";

HttpWebRequest req = (HttpWebRequest) WebRequest.Create(logoffUrlString);



32

req.Headers["Cookie: JSESSIONID"] = SessionID;

// make the HTTP call

HttpWebResponse resp = (HttpWebResponse) req.GetResponse();

if (resp.StatusCode != System.Net.HttpStatusCode.OK)

{

}

}

}

}


4 OnDemand Objects Exposed Through Web Services

This chapter contains reference information about the objects exposed through the Web Services OnDemand API. There are a number of parent and child OnDemand objects exposed. These objects enable access to data stored within an instance of CRM OnDemand.

For each of these objects, there are a number of methods that may be invoked in order to carry out a task or function. For more information on these methods, see Chapter 5, “Web Services OnDemand API Calls.”

This chapter contains the following sections:

■ “Parent Objects”

■ “Child Objects” on page 141

Parent ObjectsThe discussion of the Web services parent objects includes a description of each object, as well as information on usage of the objects and relationships between objects. The fields on which an object can be filtered and the field combinations for user key identification are also listed.

The following OnDemand objects are detailed in this section:

■ “Account” on page 34

■ “Activity” on page 48

■ “Campaign” on page 54

■ “Contact” on page 60

■ “Current User” on page 73

■ “CustomObject1” on page 75

■ “CustomObject2” on page 83

■ “Dealer” on page 91

■ “Household” on page 93

■ “Lead” on page 98

■ “LOV” on page 102

■ “Opportunity” on page 104

■ “Portfolio” on page 113

■ “Product” on page 117

■ “Product Category” on page 120


OnDemand Objects Exposed Through Web Services ■ Parent Objects

34

■ “Service Request” on page 122

■ “Solution” on page 127

■ “Territory” on page 130

■ “User” on page 132

■ “User Group” on page 135

■ “Vehicle” on page 137

NOTE: The lists of Filterable Fields and User Key combinations for the child components are offered only as a guide as they may change before the WSDLs are published.

AccountThe account object exposes the data stored in the OnDemand account object and its related child components. The methods of the account object require a list (array) of account objects as an input argument. This list of accounts identifies the records on which the operation is to be carried out. This section outlines the details of the account object and its relationship to its child objects.

Child ComponentsActivity, Contact, Lead, Opportunity, Service Request, Address, Asset, Competitor, Multiple Contact Roles, Note, Partner, Related Account, Revenue and Team

Methods CalledTable 5 details the methods called by the account service, and their names as defined on the service.

Table 5. Methods Called by Account Service

Method Name Name as Defined on Service

“Delete” on page 148 AccountDelete

“GetMapping” on page 159 NA

“Insert” on page 149 AccountInsert

“InsertOrUpdate” on page 150 AccountInsertOrUpdate

“QueryPage” on page 151 AccountQueryPage

“Update” on page 156 AccountUpdate



FieldsTable 6 details the required and read-only fields for the account object.

Table 6. Required and Read-Only Fields for the Account Object

Child Component Field Name Type

Account AccountName Required

AccountConcatField Read-only

CreatedBy Read-only

CreatedById Read-only

ModifiedBy Read-only

ModifiedById Read-only

ModifiedDate Read-only

Multiple Contact Roles

ContactRole Required

ContactId Required




CreatedDate Read-only


CreatedBy Read-only

RelatedAccount AccountRelationshipId Read-only

RelatedAccountId Read-only

Revenue RevenueId Required

PartNumber Required

Revenue Required

ContactFullName Required

CreatedBy Read-only








36

Table 7 details the status key for the account object, and the child component on which this key resides.

Table 7. Status Key for the Account Object

Child Component Field Name

Account CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedById

ModifiedDate

AccountNote CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

AccountTeam CreatedBy

CreatedById

CreatedDate

Id

ModifiedBy

ModifiedById

ModifiedDate



Activity CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

Asset CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

Competitor AccountCompetitorId

CompetitorExternalId

CompetitorId

CompetitorIntegrationId

CreatedBy

CreatedById

CreatedDate

ModifiedBy

ModifiedById

ModifiedDate





38

Contact AccountId

ContactId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

Lead AccountId

ContactId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

LeadId

ModifiedBy

ModifiedById

ModifiedDate

OpportunityId





Opportunity AccountId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

OpportunityId

RelatedAccount AccountRelationshipId

CreatedByAndDate

CreatedByDate

CreatedById

ModifiedByAndDate

ModifiedById

ModifiedDate

Revenue CreatedBy

CreatedById

CreatedDate

ExternalId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

RevenueId





40

Table 8 details the pick map fields for the account object and the child objects on which they reside.

ServiceRequest AccountId

ContactId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

ServiceRequestId

Partner AccountPartnerId

CreatedBy

CreatedById

CreatedDate

ModifiedBy

ModifiedById

ModifiedDate

PartnerExternalId

PartnerId

PartnerIntegrationId

Updated

Table 8. Pick Map Fields for the Account Object

Child Component Pick Map Field Maps To:

Account Owner OwnerId

ParentAccount, ParentAccountLocation ParentAccountId

ParentAccountIntegrationId ParentAccountId

Parent AccountExternalSystemId ParentAccountId





Table 9 provides a list of the filterable fields for the child components of the account objects, and a list of user key combinations for each child component. All parent fields on the account object are filterable.

Competitor RelatedAccountExternalId RelatedAccountId

RelatedAccountIntegrationId RelatedAccountId

Contact ContactExternalId ContactId

ContactIntegrationId ContactId



ContactExternalId ContactId

Partner RelatedAccountExternalId RelatedAccountId


Related Account RelatedAccountExternalId RelatedAccountId


Revenue Product ProductId

ProductExternalId ProductId

ProductIntegrationId ProductId

ProductCategory ProductCategoryId

ProductCategoryExternalId ProductCategoryId

ProductCategoryIntegrationId ProductCategoryId

Table 9. Filterable Fields and User Key Fields on the Account Object’s Child Components

Child Components Filterable Fields User Key Field Combinations

Account All AccountId

IntegrationId

ExternalSystemId

AccountName and Location

Account Note Subject Subject and Description

Table 8. Pick Map Fields for the Account Object




42

Account Team FirstName FirstName and Last Name

LastName

UserID

UserRole

AccountAccess

OpportunityAccess

ContactAccess

ModifiedDate

ModifiedByID

Activity Type Type and Description

Owner

Subject

DueDate

Priority

Status

Address AddressId AddressId

ExternalId ExternalId

IntegrationId IntegrationId

City

Country

ModifiedDate

Province

StateProvince

ZipCode





Asset AssetId AssetId

Contract

Date

ModifiedDate

PartNumber

ProductCategory

Product

ProjectManager

PurchaseDate

Price

Quantity

SalesRep

SerialNumber

ShipDate

Status

Type

Warranty

Contact AccountContactModifiedById ContactId

AccountContactModifiedDate Id

ContactType

ContactFirstName

ContactId

ContactLastName

Id

JobTitle

Owner

RelationshipType

RelationshipModifiedDate

RelationshipModifiedById

Competitor ModifiedDate CompetitorId





44

Lead Campaign Id

EstimatedCloseDate LeadId

Rating

Source

Status

LeadOwner

PotentialRevenue

ProductInterest

SalesPerson

LeadId

Id

Multiple Contact Roles ContactId ContactId

ContactExternalId ContactIntegrationId

ContactIntegrationId ContactExternalId

ContactRole

ModifiedDate

Opportunity Owner OpportunityId

Revenue Id

CloseDate

Forecast

ExpectedRevenue

Probability

Priority

ReasonWonLost

SalesStage

Status

OpportunityId

Id





Related Account AccountRelationshipId AccountRelationshipId

Comments RelatedAccountId

EndDate RelatedAccountExternalId

ModifiedDate RelatedAccountIntegrationId

RelatedAccountExternalId

RelatedAccountId

RelatedAccountIntegrationId

RelationshipRole

RelationshipStatus

RelationshipType

ReverseRelationshipRole

StartDate





46

Revenue ContactFullName RevenueId

Description ProductId

ExternalId ProductExternalId

IntegrationId ProductIntegrationId

Forecast

Frequency

ModifiedDate

NumberOfPeriods

Product

ProductCategoryId

ProductCategoryExternalId

ProductCategoryIntegrationId

ProductExternalId

ProductId

ProductIntegrationId

PurchasePrice

Quantity

Revenue

RevenueId

StartCloseDate

Status

Type





Table 10 details the list of value fields available for the account object.

Service Request Subject Id

Area ServiceRequestId

Owner

Priority

Type

Cause

Source

Status

Id

ServiceRequestId

Table 10. Picklists Available for the Account Object

Child Component Field Name LOV Type

Account AccountType ACCOUNT_TYPE

Priority ACCOUNT_PRIORITY

Region TRAINING_LOC_REGION

CallFrequency PHMA_CALL_FREQUENCY

InfluenceType ACC_PRI_INFL_TYPE

Route PHMA_ROUTE

Status ACCOUNT_STATUS

MarketPotential PHMA_RATING

MarketingSegment PRIM_MARKET

Account Team TeamRole ACCOUNT_TEAM_TEAM_ROLE

Competitor Role PARTY_REL_TYPE


ContactRole ACCOUNT_CONTACT_ROLE

Partner Role PARTY_REL_TYPE

RelatedAccount Relationship PARTY_REL_TYPE

Status PARTY_RELATIONSHIP_STATUS





48

Table 11 details a number of account object fields that you must not use for customer integrations.

For more information on the fields exposed through the account Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the account object.

See AlsoContact

ActivityThe activity object stores information on an activity that a user must carry out — for example, a call-back activity for an account. When an activity is created, set the display field explicitly to Task or Appointment.

UsageSiebel OnDemand Web Services uses activities to organize, track, and resolve a variety of tasks, from finding and pursuing opportunities to closing service requests. If a task requires multiple steps that one or more people may carry out, activities greatly simplify the job. Activities can help:

■ Define and assign the task

■ Provide information to complete the task

■ Track the progress of the task

■ Track costs and bill for the task

Revenue Type REVENUE_TYPE

Status STATUS

Frequency LOV_FREQUENCY_TYPE

Table 11. Account Object Fields Not to Be Used

Field Name

CustomerAccountGroup

GroupTypeCode

InternalOrgFlag

Table 10. Picklists Available for the Account Object




Parent ServicesAccount, Campaign, Contact, Lead, Opportunity and Service Request

Child ComponentsContact and User

Methods CalledTable 12 details the methods called by the activity service, and their names as defined on the service.

FieldsTable 13 details the required and read-only fields for the activity object.

Table 12. Methods Called by Activity Service


“Delete” on page 148 ActivityDelete


“Insert” on page 149 ActivityInsert

“InsertOrUpdate” on page 150 ActivityInsertOrUpdate

“QueryPage” on page 151 ActivityQueryPage

“Update” on page 156 ActivityUpdate

Table 13. Required and Read-Only Fields for the Activity Object


Activity Subject Required

Display Required

ActivityId Read-only

ContactFirstName Read-only

ContactLastName Read-only

LeadFirstName Read-only

LeadLastName Read-only

MedEdEventName Read-only

OpportunityName Read-only

FundRequest Read-only



50

Table 14 details the status key for the activity object.

Contact ContactId Read-only



ContactAccountId Read-only

ContactAccountName Read-only

ContactAccountLocation Read-only

ContactAccountIntegrationId Read-only

ContactAccountExternalSystemId Read-only

User UserId Read-only

UserEmail Read-only

UserFirstName Read-only

UserLastName Read-only

UserRole Read-only

Table 14. Status Key for the Activity Object


Activity ActivityId

CreatedBy

CreatedByAndDate

CreatedTimestamp

ExternalSystemId

IntegrationId

ModifiedBy

ModifiedByAndDate

ModifiedTimestamp

Table 13. Required and Read-Only Fields for the Activity Object




Contact ActivityContactId

ContactIntegrationId

ContactExternalSystemId

ContactId

CreatedByAndDate

CreatedById

CreatedDate

ModifiedByAndDate

ModifiedById

ModifiedDate

User CreatedByAndDate

CreatedById

CreatedDate

Id

ModifiedByAndDate

ModifiedById

ModifiedDate

UserExternalId

UserIntegrationId

Table 14. Status Key for the Activity Object




52

Table 15 details the pick map fields for the activity object and the child objects on which they reside.

Table 15. Pick Map Fields for the Activity Object


Activity AccountName AccountId

AccountLocation AccountId

AccountExternalSystemId AccountId

AccountIntegration AccountId

Owner OwnerId

CampaignExternalSystemId CampaignId

CampaignIntegrationId CampaignId

CampaignName CampaignId

LeadExternalSystemId LeadId

LeadIntegrationId LeadId

MedEdEventExternalSystemId MedEdEventId

MedEdEventIntegrationId MedEdEventId

OpportunityExternalSystemId OpportunityId

OpportunityIntegrationId OpportunityId

ServiceRequestNumber ServiceRequestId

ServiceRequestExternalSystemId ServiceRequestId

ServiceRequestIntegrationId ServiceRequestId

FundRequestExternalSystemId FundRequestId

FundRequestIntegrationId FundRequestId



User UserExternalId UserId

UserIntegrationId UserId



Table 16 provides a list of the filterable fields for the child components of the activity objects, and a list of user key combinations for each child component. All parent fields on the activity object are filterable.

Table 16. Filterable Fields and User Key Fields on the Activity Object’s Child Components


Activity All ActivityId

IntegrationId

ExternalSystemId

Contact ContactId ContactId

ContactExternalId ContactExternalId

ContactIntegrationId ContactIntegrationId

ContactFirstName

ContactLastName

ContactAccountId

ContactAccountName

ContactAccountLocation

ContactAccountIntegrationId

ContactAccountExternalSystemId

ModifiedDate

User ModifiedDate UserId

UserId UserExternalId

UserExternalId UserIntegrationId

UserIntegrationId

UserEmail

UserFirstName

UserLastName

UserRole



54

Table 17 details the picklists available for the activity object.

For more information on the fields exposed through the activity Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the activity object.

CampaignThe campaign object provides a mechanism for marketing products and services to customers and prospects. The campaign object is the primary way in which new products and services are marketed to customers and prospects.

Table 17. Picklists Available for the Activity Object

Field Name LOV Type

AccountName ACCOUNT_ID

AccountLocation ACCOUNT_ID

AccountIntegrationId ACCOUNT_ID

AccountExternalSystemId ACCOUNT_ID

OpportunityName OPPORTUNITY_ID

ServiceRequestNumber SERVICE_REQUEST_ID

ServiceRequestIntegrationId SERVICE_REQUEST_ID

ServiceRequestExternalSystemId SERVICE_REQUEST_ID

DelegatedByExternalSystemId DELEGATED_ID

PrimaryContactIntegrationId PRIMARY_CONTACT_ID

PrimaryContactExternalSystemId PRIMARY_CONTACT_ID

MedEdEventIntegrationId MED_ED_EVENT_ID

MedEdEventExternalSystemId MED_ED_EVENT_ID

FundRequestExternalId FUND_REQUEST_ID

LeadIntegrationId LEAD_ID

LeadExternalSystemId LEAD_ID

CampaignIntegrationId CAMPAIGN_ID

CampaignExternalSystemId CAMPAIGN_ID

ActivitySubtype COD_TODO_SUBTYPE

ResolutionCode COD_RESOLUTION_CODE



Parent ServiceLead

Child ComponentsActivity, Contact, Lead, Opportunity and Note

Methods CalledTable 18 details the methods called by the campaign service, and their names as defined on the service.

FieldsTable 19 details the required and read-only fields for the campaign object.

Table 18. Methods Called by Campaign Service


“Delete” on page 148 CampaignDelete


“Insert” on page 149 CampaignInsert

“InsertOrUpdate” on page 150 CampaignInsertOrUpdate

“QueryPage” on page 151 CampaignQueryPage

“Update” on page 156 CampaignUpdate

Table 19. Required and Read-Only Fields for the Campaign Object

Field Name Type

CampaignName Required

SourceCode Required

CreatedBy Read-only

CreatedByFullName Read-only



LastUpdated Read-only






56

Table 20 details the status key for the campaign object.

Table 20. Status Key for the Campaign Object


Campaign CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

Activity CampaignId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate



CampaignNote CampaignId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate

Lead CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate

Opportunity CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate





58

Table 21 details the pick map field for the campaign object.

Table 22 provides a list of the filterable fields for the child components of the campaign objects, and a list of user key combinations for each child component. All parent fields on the campaign object are filterable.

Recipient CampaignContactId

ContactExtrernalId


ContactId

CreatedByAndDate

CreatedById

CreatedDate

ModifiedByAndDate

ModifiedById

ModifiedDate

Table 21. Pick Map Field for the Campaign Object

Pick Map Field Maps To:

Owner OwnerId

Table 22. Filterable Fields and User Key Fields on the Campaign Object’s Child Components


Campaign All CampaignId

IntegrationId

ExternalSystemID






Owner

Subject

DueDate

Priority

Status

Campaign Note Subject Subject and Description

Lead Campaign FirstName

EstimatedCloseDate Description

Rating

Source

Status

LeadOwner

PotentialRevenue

ProductInterest

SalesPerson

Opportunity Account OpportunityName

Owner

Revenue

CloseDate

Forecast

ExpectedRevenue

Probability

Priority

ReasonWonLost

SalesStage

Status

Table 22. Filterable Fields and User Key Fields on the Campaign Object’s Child Components




60

Table 23 details the picklists available for the campaign object.

For more information on the fields exposed through the campaign Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the campaign object.

See AlsoCurrent User and Opportunity

ContactThe contact object stores information on individuals with whom your organization has a relationship. It allows the user to store information on individuals who are external to your company, but who are associated with the business process. Contacts stored in the OnDemand database may also be associated with an account.

Parent ServicesAccount, Activity, Campaign, Household, Opportunity, Portfolio and Vehicle

Child ComponentsActivity, Lead, Opportunity, Service Request, Note, Related Contact, Revenue and Team

Table 23. Picklists Available for the Campaign Object


Campaign CampaignType CAMPAIGN_TYPE

Status CAMPAIGN_STATE

Contact DeliveryStatus DELIVERY_STATUS

ResponseStatus RESPONSE_STATUS



Methods CalledTable 24 details the methods called by the contact service, and their names as defined on the service.

FieldsTable 25 details the required and read-only fields for the contact object.

Table 24. Methods Called by Contact Service


“Delete” on page 148 ContactDelete


“Insert” on page 149 ContactInsert

“InsertOrUpdate” on page 150 ContactInsertOrUpdate

“QueryPage” on page 151 ContactQueryPage

“Update” on page 156 ContactUpdate

Table 25. Required and Read-Only Fields for the Contact Object


Contact FirstName Required

LastName Required

ContactConcatField Read-only

ContactFullName Read-only

CreatedBy Read-only



Manager Read-only




Address AddressId Read-only

Contact Team ContactTeamId Read-only



UserRole Read-only



62

Table 26 details the status key for the contact object.

Related Contact ContactRelationshipId Read-only

ContactId Read-only

RelatedContactFirstName Read-only

RelatedContactLastName Read-only

Revenue RevenueId Required

PartNumber Required

Revenue Required

ContactFullName Required

CreatedBy Read-only






Table 26. Status Key for the Contact Object


Contact AccountId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate

Table 25. Required and Read-Only Fields for the Contact Object




Activity CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

ContactNote ContactId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate





64

Lead AccountId

CampaignId

ContactId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

LeadId

ModifiedBy

ModifiedById

ModifiedDate

OpportunityId


CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

LeadId

ModifiedBy

ModifiedById

ModifiedDate

OpportunityId





RelatedContact ContactRelationshipId

CreatedByAndDate

CreatedByDate

CreatedById

ModifiedByAndDate

ModifiedByDate

ModifiedById

RelatedContactId

Revenue CreatedBy

CreatedById

CreatedDate

ExternalId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

RevenueId


ContactID

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

ServiceRequestId





66

Table 27 details the pick map fields for the contact object.

Team ContactTeamId

CreatedBy

CreatedById

CreatedDate

ModifiedBy

ModifiedById

ModifiedDate

UserExternalSystemId

UserId

UserIntegrationId

Table 27. Pick Map Fields for the Contact Object


Contact AccountName AccountId

Owner AssignedToAlias

SourceCampaignName SourceCampaignId

ManagerExternalSystemId ManagerId

Contact Team UserExternalSystemId UserId


Related Contact RelatedContactExternalId RelatedContactId

RelatedContactIntegrationId RelatedContactId

Revenue Product ProductId



ProductCategory ProductCategoryId

ProductCategoryExternalId ProductCategoryId

ProductCategoryIntegrationId ProductCategory





Table 28 provides a list of the filterable fields for the child components of the contact objects, and a list of user key combinations for each child component. All parent fields on the contact object are filterable.

Table 28. Filterable Fields and User Key Fields on the Contact Object’s Child Components


Contact All ContactId

IntegrationId

ExternalSystemId


Owner

Subject

DueDate

Priority

Status

Address AddressID AddressID



City

Country

ZipCode

StateProvince

Province

Contact Note Subject Subject and Description

Contact Team ContactTeamId

UserId


UserIntegrationId

UserFirstName

UserLastName

ContactAccess

UserRole



68

Lead Campaign

EstimatedCloseDate

Rating

Source

Status

LeadOwner

PotentialRevenue

ProductInterest

SalesPerson

LeadId

OpportunityId

Opportunity Opportunity

OpportunityId

Owner

Revenue

CloseDate

Forecast

ExpectedRevenue

Probability

Priority

ReasonWonLost

SalesStage

Status

Account





Personal Address PersonalAddressIntegrationId

PersonalAddressName

AlternateCity

AlternateCountry

AlternateZipCode

AlternateStateProvince

AlternateAddress

AlternateAddress2

AlternateAddress3

Id

IntegrationId

AddressName

City

Country

ZipCode

StateProvince

Address

ShippingAddress2

Related Contact ContactRelationshipId

RelatedContactId

RelatedContactExternalId

RelatedContactIntegrationId

RelationshipStatus

RelationshipType

StartDate

EndDate

Description

RelationshipRole

ReverseRelationshipRole





70

Revenue ContactFullName RevenueId

Description ExternalId

ExternalId IntegrationId

Forecast

Frequency

IntegrationId

ModifiedDate

NumberOfPeriods

Product

ProductId

ProductCategoryId

ProductCategory

ProductCategoryExternalId

ProductCategoryIntegrationId

ProductExternalId

ProductIntegrationId

PurchasePrice

Quantity

Revenue

RevenueId

Status

StartCloseDate

Type





Service Request Subject SRNumber

Area

Owner

Priority

Type

Cause

Source

Status

ServiceRequestId





72

Table 29 details the picklists available for the contact object.

Table 29. Picklists Available for the Contact Object


Contact ContactType CONTACT_TYPE

LeadSource OCCAM_LEAD_SOURCE

MrMrs MR_MRS

BestTimeToCall FINCORP_CONTACT_CALL_TIME

CallFrequency PROF_CALL_CLASS

CurrentInvestmentMix VONDINS_INVESTMENT_MIX

Degree PROF_DEGREE

ExperienceLevel FINS_INVST_EXPR_CD

Gender SEX_MF

InvestmentHorizon FINS_INV_HORIZON

LifeEvent FIN_CON_LIFE_EVENTS

MaritalStatus MARITAL_STATUS

MarketPotential PHARMA_MARKET_POT

Objective FINCORP_INVESTOR_OBJECTIVES

OwnOrRent FIN_HOUSING_TYPE

PrimaryGoal FINS_GOALS

RiskProfile FINS_INVST_RISK_CD

Route PROF_ROUTE

Segment FIN_CONTACT_DEPARTMENT

Tier FIN_CON_VALUE_TYPE

Contact Team TeamRole CONTACT_TEAM_TEAM_ROLE

Related Contact Relationship PARTY_REL_TYPE

Status CON_PARTY_RELATIONSHIP_STATUS

Revenue Type REVENUE_TYPE

Status STATUS

Frequency LOV_FREQUENCY_TYPE



Table 30 details a number of contact object fields that you must not use for customer integrations.

For more information on the fields exposed through the contact Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the contact object.

Current UserThe current user object stores information on the currently logged-in user.

Child ComponentsLogin History and Quota

Methods CalledTable 31 details the method called by the current user service, and its name as defined on the service.

Table 30. Contact Object Fields That You Must Not Use

Field Name

PartyTypeCode

PartyUId

PersonUId

Table 31. Methods Called by Current User Service



“QueryPage” on page 151 CurrentUserQueryPage



74

FieldsTable 32 details the required and read-only fields for the current user object.

Table 33 provides a list of the filterable fields for the child components of the current user objects, and a list of user key combinations for each child component. All parent fields on the current user object are filterable.

For more information on the fields exposed through the current user Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the current user object.

See AlsoUser

Table 32. Required and Read-Only Fields for the Current User Object


Current User FirstName Required

LastName Required

CreatedBy Read-only


Login History LastLoggedIn Read-only

Table 33. Filterable Fields on the Current User Object’s Child Components

Child Component XML Tag in WSDL User Key Field Combinations

Current User All CurrentUserId

IntegrationId

ExternalSystemId

FirstName and LastName and Middlename

Login History Alias

SourceIPAddress

SignInStatus

SignInTime



CustomObject1This service exposes the functionality of the CustomObject1 OnDemand object to external applications.

NOTE: To download the CustomObject1 WSDL, you must be given access to the CustomObject1 object. If you do not have access to the CustomObject1 object, it will not be available to download from the Web Services Administration screen or available to use the vertical Web service calls. For assistance in gaining access to the CustomObject1 object, contact your Siebel CRM OnDemand service provider.

Child ComponentsAccount, Contact, CustomObject2, Opportunity, Portfolio and Team

Methods CalledTable 34 details the methods called by the CustomObject1 service, and their names as defined on the service.

FieldsTable 35 details the required and read-only fields for the CustomObject1 object.

Table 34. Methods Called by CustomObJect1 Service


“Delete” on page 148 CustomObject1Delete


“Insert” on page 149 CustomObject1Insert

“InsertOrUpdate” on page 150 CustomObject1OrUpdate

“QueryPage” on page 151 CustomObject1Page

“Update” on page 156 CustomObject1Update

Table 35. Required and Read-Only Fields for the CustomObject1 Object


CustomObject1 CustomObject1Id Required

CustomObject1ExternalSystemID Required

CustomObject1IntegrationId Required

CustomObject1Id Read-only



76

Account CObj1AccountCreatedById Read-only

CObj1AccountCreatedDate Read-only

CObj1AccountModifiedById Read-only

CObj1AccountModifiedDate Read-only

Region Read-only

AccountType Read-only

Contact CObj1ContactCreatedById Read-only

CObj1ContactCreatedDate Read-only

CObj1ContactModifiedById Read-only

CObj1ContactModifiedDate Read-only



ContactType Read-only

CustomObject2 CObj1CustomObject2CreatedById Read-only

CObj1CustomObject2CreatedDate Read-only

CObj1CustomObject2ModifiedById Read-only

CObj1CustomObject2ModifiedDate Read-only


Opportunity AccountName Read-only

CObj1OpportunityCreatedById Read-only

CObj1OpportunityCreatedDate Read-only

CObj1OpportunityModifiedById Read-only

CObj1OpportunityModifiedDate Read-only


Revenue Read-only

SalesStage Read-only





Table 36 details the status key for the CustomObject1 object.

Portfolio AccountNumber Read-only

CObj1PortfolioCreatedById Read-only

CObj1PortfolioCreatedDate Read-only

CObj1PortfolioModifiedById Read-only

CObj1PortfolioModifiedDate Read-only

Revenue Read-only

Team CustomObject1TeamId Read-only



Table 36. Status Key for the CustomObject1 Object


CustomObject1 CustomObject1Id

ExternalSystemId

IntegrationId

CreatedBy

CreatedById

CreatedDate

ModifiedBy

ModifiedById

ModifiedDate

Account CustomObject1AccountId

CObj1AccountCreatedById

CObj1AccountCreatedDate

CObj1AccountModifiedById

CObj1AccountModifiedDate





78

Contact CustomObject1ContactId

CObj1ContactCreatedById

CObj1ContactCreatedDate

CObj1ContactModifiedById

CObj1ContactModifiedDate


CObj1CustomObject2CreatedById

CObj1CustomObject2CreatedDate

CObj1CustomObject2ModifiedById

CObj1CustomObject2ModifiedDate

Opportunity OpportunityId

CObj1OpportunityCreatedById

CObj1OpportunityCreatedDate

CObj1OpportunityModifiedById


Portfolio PortfolioId

CObj1PortfolioCreatedById

CObj1PortfolioCreatedDate

CObj1PortfolioModifedById

CObj1PortfolioModifiedDate

Team CustomObject1TeamId

CreatedBy

CreatedById

CreatedDate

ModifiedBy

ModifiedById

ModifiedDate





Table 37 details the pick map fields for the CustomObject1 object.

Table 37. Pick Map Fields for the CustomObject1 Object


CustomObject1 AccountExternalId AccountId

AccountIntegrationId AccountId

AccountName AccountId

ActivityExternalId ActivityId

ActivityIntegrationId ActivityId

ActivityName ActivityId

CampaignExternalId CampaignId




ContactFirstName ContactId

ContactFullName ContactId


ContactLastName ContactId

CustomObject2ExternalId CustomObject2Id

CustomObject2IntegrationId CustomObject2Id

CustomObject2Name CustomObject2Id




DealerName DealerId

HouseholdExternalId HouseholdId

HouseholdIntegrationId HouseholdId

HouseholdName HouseholdId

LeadExternalId LeadId

LeadFirstName LeadId

LeadFullName LeadId




80

CustomObject1 (contd.)

LeadLastName LeadId

Owner OwnerId

OpportunityExternalId OpportunityId


OpportunityName OpportunityId

ParentExternalSystemId ParentId

ParentIntegrationId ParentId

PortfolioAccountNumber PortfolioId



ProductName ProductId

SolutionExternalId SolutionId

SolutionIntegrationId SolutionId

SolutionTitle SolutionId

ServiceRequestExternalId ServiceRequestId


ServiceRequestName ServiceRequestId

VIN VehicleId

Account ExternalSystemId AccountId

IntegrationId AccountId

Location AccountId

Name AccountId

Contact ExternalSystemId ContactId

IntegrationId ContactId

CustomObject2 Owner OwnerId

Opportunity ExternalSystemId OpportunityId

IntegrationId OpportunityId

Portfolio ExternalSystemId PortfolioId

IntegrationId PortfolioId





Table 38 provides a list of the filterable fields for the child components of the CustomObject1 object, and a list of user key combinations for each child component. All parent fields on the CustomObject1 object are filterable.

Team UserExternalSystemId UserId


UserEmail UserId

Table 38. Filterable Fields and User Key Fields on the CustomObject1 Object’s Child Components


CustomObject1 All CustomObject1Id

ExternalSystemId

IntegrationId

Account AccountId CustomObject1AccountId

AccountType ExternalSystemId

CObj1AccountModifiedById IntegrationId


ExternalSystemId

IntegrationId

Location

Name

Region

Contact ContactId CustomObject1ContactId

CObj1ContactModifiedById ExternalSystemId

CObj1ContactModifiedDate IntegrationId

ContactType

ExternalSystemId

IntegrationId





82

Table 39 details the picklist available for the CustomObject1 object.

CustomObject2 CustomObject2Id CustomObject2Id

CObj1CustomObject2ModifiedById ExternalSystemId

CObj1CustomObject2ModifiedDate IntegrationId

ExternalSystemId

IntegrationId

Name

Type

Opportunity CObj1OpportunityModifiedById OpportunityId

CObj1OpportunityModifiedDate ExternalSystemId

ExternalSystemId IntegrationId

IntegrationId

OpportunityId

Portfolio CObj1PortfolioModifiedById PortfolioId

CObj1PortfolioModfiedDate ExternalSystemId


IntegrationId

PortfolioId

Team CustomObject1TeamId CustomObject1TeamId

UserEmail UserExternalSystemId

UserExternalSystemId UserIntegrationId

UserId

UserIntegrationId

Table 39. Picklists Available for the CustomObject1 Object


Dealer Type OCC_CUST_LOV_ACCOUNT_0 to OCC_CUST_LOV_ACCOUNT_99

Household Type OCC_CUST_LOV_HOUSEHOLD_0 to OCC_CUST_LOV_HOUSEHOLD_99





CustomObject2This service exposes the functionality of the CustomObject2 OnDemand object to external applications.

NOTE: To download the CustomObject2 WSDL, you must be given access to the CustomObject2 object. If you do not have access to the CustomObject2 object, it will not be available to download from the Web Services Administration screen or available to use the vertical Web service calls. For assistance in gaining access to the CustomObject2 object, contact your Siebel CRM OnDemand service provider.

Child ComponentsAccount, Contact, CustomObject1, Opportunity, Portfolio and Team

Methods CalledTable 40 details the methods called by the CustomObject2 service, and their names as defined on the service.

Portfolio Type OCC_CUST_LOV_ASSET_0 to OCC_CUST_LOV_ASSET_99

Vehicle Type OCC_CUST_LOV_ASSET_0 to OCC_CUST_LOV_ASSET_99

Table 40. Methods Called by CustomObJect2 Service


“Delete” on page 148 CustomObject2Delete


“Insert” on page 149 CustomObject2Insert

“InsertOrUpdate” on page 150 CustomObject2OrUpdate

“QueryPage” on page 151 CustomObject2Page

“Update” on page 156 CustomObject2Update





84

FieldsTable 41 details the required and read-only fields for the CustomObject2 object.



CustomObject1 CustomObject2Id Required

CustomObject2ExternalSystemID Required

CustomObject2IntegrationId Required


Account AccountType Read-only

CObj2AccountCreatedById Read-only

CObj2AccountCreatedDate Read-only

CObj2AccountModifiedById Read-only

CObj2AccountModifiedDate Read-only

Region Read-only

Contact ContactFirstName Read-only


ContactType Read-only

CObj2ContactCreatedById Read-only

CObj2ContactCreatedDate Read-only

CObj2ContactModifiedById Read-only

CObj2ContactModifiedDate Read-only

CustomObject1 CObj2CustomObject1CreatedById Read-only

CObj2CustomObject1CreatedDate Read-only

CObj2CustomObject1ModifiedById Read-only

CObj2CustomObject1ModifiedDate Read-only




Table 42 details the status key for the CustomObject2 object.

Opportunity AccountName Read-only

CObj2OpportunityCreatedById Read-only

CObj2OpportunityCreatedDate Read-only

CObj2OpportunityModifiedById Read-only

CObj2OpportunityModifiedDate Read-only

Name Read-only

Revenue Read-only

SalesStage Read-only

Portfolio AccountNumber Read-only

CObj2PortfolioCreatedById Read-only

CObj2PortfolioCreatedDate Read-only

CObj2PortfolioModifiedById Read-only

CObj2PortfolioModifiedDate Read-only

Revenue Read-only

Team CustomObject2TeamId Read-only






ExternalSystemId

IntegrationId

CreatedBy

CreatedById

CreatedDate

ModifiedBy

ModifiedById

ModifiedDate





86

Account CustomObject2AccountId

CObj2AccountCreatedById

CObj2AccountCreatedDate

CObj2AccountModifiedById


Contact CustomObject2ContactId

CObj2ContactCreatedById

CObj2ContactCreatedDate

CObj2ContactModifiedById

CObj2ContactModifiedDate


CObj2CustomObject1CreatedById

CObj2CustomObject1CreatedDate

CObj2CustomObject1ModifiedById

CObj2CustomObject1ModifiedDate

Opportunity OpportunityId

CObj2OpportunityCreatedById


CObj2OpportunityModifiedById


Portfolio PortfolioId

CObj2PortfolioCreatedById

CObj2PortfolioCreatedDate

CObj2PortfolioModifedById

CObj2PortfolioModifiedDate





Table 43 details the pick map fields for the CustomObject2 object.

Team CustomObject2TeamId

CreatedBy

CreatedById

CreatedDate

ModifiedBy

ModifiedById

ModifiedDate



CustomObject2 AccountExternalId AccountId


AccountName AccountId

ActivityExternalId ActivityId

ActivityIntegrationId ActivityId

ActivityName ActivityId

CampaignExternalId CampaignId




ContactFirstName ContactId

ContactFullName ContactId


ContactLastName ContactId










88

CustomObject2 (contd.)


DealerName DealerId

HouseholdExternalId HouseholdId

HouseholdIntegrationId HouseholdId

HouseholdName HouseholdId

LeadExternalId LeadId

LeadFirstName LeadId

LeadFullName LeadId


LeadLastName LeadId

Owner OwnerId

OpportunityExternalId OpportunityId



ParentExternalSystemId ParentId

ParentIntegrationId ParentId

PortfolioAccountNumber PortfolioId



ProductName ProductId

SolutionExternalId SolutionId

SolutionIntegrationId SolutionId

SolutionTitle SolutionId

ServiceRequestExternalId ServiceRequestId


ServiceRequestName ServiceRequestId

VIN VehicleId

Account ExternalSystemId AccountId

IntegrationId AccountId

Location AccountId

Name AccountId





Table 44 provides a list of the filterable fields for the child components of the CustomObject2 object, and a list of user key combinations for each child component. All parent fields on the CustomObject2 object are filterable.

Contact ExternalSystemId ContactId

IntegrationId ContactId

CustomObject1 Owner OwnerId

Opportunity ExternalSystemId OpportunityId

IntegrationId OpportunityId

Portfolio ExternalSystemId PortfolioId

IntegrationId PortfolioId

Team UserExternalSystemId UserId


UserEmail UserId



CustomObject2 All CustomObject2Id

ExternalSystemId

IntegrationId

Account AccountId CustomObject2AccountId

AccountType ExternalSystemId

CObj2AccountModifiedById IntegrationId


ExternalSystemId

IntegrationId

Location

Name

Region





90

Contact CObj2ContactModifiedById CustomObject2ContactId

CObj2ContactModifiedDate ExternalSystemId

ContactId IntegrationId

ContactType

ExternalSystemId

IntegrationId

CustomObject1 CObj2CustomObject1ModifiedById CustomObject1Id

CObj2CustomObject1ModifiedDate ExternalSystemId

CustomObject1Id IntegrationId

CustomObject1Name

ExternalSystemId

IntegrationId

Type

Opportunity CObj2OpportunityModifiedById OpportunityId

CObj2OpportunityModifiedDate ExternalSystemId


IntegrationId

OpportunityId

Portfolio CObj2PortfolioModifiedById PortfolioId

CObj2PortfolioModfiedDate ExternalSystemId


IntegrationId

PortfolioId

Team CustomObject2TeamId CustomObject2TeamId

UserEmail UserExternalSystemId

UserExternalSystemId UserIntegrationId

UserId

UserIntegrationId





Table 45 details the picklist available for the CustomObject2 object.

DealerThe dealer object stores information about dealerships in the automotive industry, for example, the name of the dealership, the identity of the parent dealership, the site on which the dealership is based, and so on. The dealer object does not have any parent services or child components.

NOTE: To download the Dealer WSDL, you must be given access to the Dealer object. If you do not have access to the Dealer object, it will not be available to download from the Web Services Administration screen or available to use the vertical Web service calls. For assistance in gaining access to the Dealer object, contact your Siebel CRM OnDemand service provider.

Methods CalledTable 46 details the methods called by the dealer service, and their names as defined on the service.



Dealer Type OCC_CUST_LOV_ACCOUNT_0 to OCC_CUST_LOV_ACCOUNT_99

Household Type OCC_CUST_LOV_HOUSEHOLD_0 to OCC_CUST_LOV_HOUSEHOLD_99

Portfolio Type OCC_CUST_LOV_ASSET_0 to OCC_CUST_LOV_ASSET_99

Vehicle Type OCC_CUST_LOV_ASSET_0 to OCC_CUST_LOV_ASSET_99

Table 46. Methods Called by Dealer Service


“Delete” on page 148 DealerDelete


“Insert” on page 149 DealerInsert

“InsertOrUpdate” on page 150 DealerInsertOrUpdate

“QueryPage” on page 151 DealerQueryPage

“Update” on page 156 DealerUpdate



92

FieldsAll fields on the dealer object are filterable.

Table 47 details the required and read-only fields for the dealer object.

Table 48 details the status key for the dealer object.

Table 49 details the pick map fields for the dealer object.

Table 47. Required and Read-Only Fields for the Dealer Object

Field Name Type

DealerId Required

DealerIntegrationId Required

DealerExternalSystemID Required

DealerId Read-only

DealerType Read-only

Table 48. Status Key for the Dealer Object


Dealer CreatedBy

CreatedById

CreatedDate

DealerId

DealerIntegrationID

DealerExternalSystemId

ModifiedBy

ModifiedById

ModifiedDate

Table 49. Pick Map Fields for the Dealer Object


Owner OwnerId

ParentDealerExternalSystemId ParentDealerId



Table 50 details the picklists available for the dealer object.

For more information on the fields exposed through the household Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the household object.

HouseholdThe household object allows you to define and record financial details about a group of contacts that live in the same household, for example, parents, brothers, sisters, spouses, and so on. These details include the assets of the household, the liabilities of the household, the net income of the household, and so on.

NOTE: To download the Household WSDL, you must be given access to the Household object. If you do not have access to the Household object, it will not be available to download from the Web Services Administration screen or available to use the vertical Web service calls. For assistance in gaining access to the Household object, contact your Siebel CRM OnDemand service provider.

Child ComponentContact

ParentDealerIntegrationId ParentDealerId

ParentDealerName ParentDealerId

ParentDealerSite ParentDealerId

Table 50. Picklists Available for the Dealer Object

Field Name LOV Type

ParentDealerName ParentDealerId

ParentDealerSite ParentDealerId

Table 49. Pick Map Fields for the Dealer Object




94

Methods CalledTable 51 details the methods called by the household service, and their names as defined on the service.

Table 51. Methods Called by Household Service


“Delete” on page 148 HouseholdDelete


“Insert” on page 149 HouseholdInsert

“InsertOrUpdate” on page 150 HouseholdInsertOrUpdate

“QueryPage” on page 151 HouseholdQueryPage

“Update” on page 156 HouseholdUpdate



FieldsTable 52 details the required and read-only fields for the household object.

Table 52. Required and Read-Only Fields for the Household Object


Household HouseholdName Required

IntegrationID Required

ExternalSystemID Required

HouseholdId Read-only

PrimaryContactId Read-only

PrimaryContactExternalId Read-only

PrimaryContactIntegrationId Read-only

PrimaryContactFirstName Read-only

PrimaryContactLastName Read-only

Timezone Read-only

HouseholdCurrency Read-only

LastActivity Read-only

HeadDOB Read-only

TotalIncome Read-only

TotalAssets Read-only

TotalExpenses Read-only

TotalLiabilities Read-only

TotalNetWorth Read-only

RiskProfile Read-only

ExperienceLevel Read-only

InvestmentHorizon Read-only

CurrentInvestmentMix Read-only

Objective Read-only

PrimaryGoal Read-only



96

Table 53 details the status key for the household object.

Contact ContactId Required

ContactExternalId Required

ContactIntegrationId Required



ContactId Read-only

ContactMrMrs Read-only

Table 53. Status Key for the Household Object


Household CreatedBy

CreatedById

CreatedDate

ExternalSystemId

HouseholdId

IntegrationID

ModifiedBy

ModifiedById

ModifiedDate

Contact CreatedBy

CreatedById

CreatedDate

ContactId

ModifiedBy

ModifiedById

ModifiedDate

Table 52. Required and Read-Only Fields for the Household Object




Table 54 details the pick map fields for the household object.

Table 55 provides a list of the filterable fields for the child components of the household object, and a list of user key combinations for each child component. All parent fields on the household object are filterable.

Table 56 details the picklists available for the household object.

For more information on the fields exposed through the household Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the household object.

Table 54. Pick Map Field for the Household Object




Table 55. Filterable Fields and User Key Fields on the Household Object’s Child Components


Household All HouseholdId

IntegrationID

ExternalSystemID

Contact ContactID ContactID



ModifiedDate

RelationshipRole

Table 56. Picklists Available for the Household Object


Household Segment HOUSEHOLD_SEGMENT

Type HOUSEHOLD_TYPE

Contact RelationshipRole REL_TO_HOUSEHOLD



98

LeadThe lead object stores information on a company or individual with whom an opportunity may be created and worked. It allows the user to identify the companies that may be interested in a product or service. Leads are usually generated as part of a marketing campaign.

Parent ServicesAccount, Campaign, Contact and Opportunity

Child ComponentsActivity and Campaign

Methods CalledTable 57 details the methods called by the lead service, and their names as defined on the service.

FieldsTable 58 details the required and read-only fields for the lead object.

Table 57. Methods Called by Lead Service


“Delete” on page 148 LeadDelete


“Insert” on page 149 LeadInsert

“InsertOrUpdate” on page 150 LeadInsertOrUpdate

“QueryPage” on page 151 LeadQueryPage

“Update” on page 156 LeadUpdate

Table 58. Required and Read-Only Fields for the Lead Object

Field Name Type

FirstName Required

LastName Required

LeadOwner Required


CreatedBy Read-only




Table 59 details the status key for the lead object.



LeadConcatField Read-only

LeadFullName Read-only




Table 59. Status Key for the Lead Object


Lead AccountId

CampaignId

ContactId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate

OpportunityId

Table 58. Required and Read-Only Fields for the Lead Object

Field Name Type



100

Table 60 details the pick map fields for the lead object.

Activity CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LeadId

ModifiedBy

ModifiedById

ModifiedDate

Table 60. Pick Map Fields for the Lead Object


Campaign CampaignId


Owner OwnerId


OpportunityExternalSystemId OpportunityId

ContactExternalSystemId ContactId

CampaignExternalSystemId CampaignId

Table 59. Status Key for the Lead Object




Table 61 provides a list of the filterable fields for the child components of the lead object, and a list of user key combinations for each child component. All parent fields on the lead object are filterable.

Table 62 details the picklists available for the lead object.

For more information on the fields exposed through the lead Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the lead object.

Table 61. Filterable Fields and User Key Fields on the Lead Object’s Child Components


Lead All LeadId

IntegrationId

ExternalSystemId

LeadFirstName and LeadLastName

Description


Owner

Subject

DueDate

Priority

Status

Table 62. Picklists Available for the Lead Object

Field Name LOV Type

Country COUNTRY

MrMrs MR_MRS

Rating OCCAM_LEAD_RATING

Source OCCAM_LEAD_SOURCE

StateProvince STATE_ABBREV

Status OCCAM_LEAD_SOURCE



102

LOVThe LOV object stores information on a list of values for a specified static picklist. Using the GetListOfValues method with this object allows a user to return a list of values for a static drop-down list. For example, if you want to get a list of all the possible types that an Activity can have, you use the GetListOfValues method with the LOVType parameter set to TODO_TYPE. This returns all possible values for the type of a Task.

There are three fields—OpportunitySalesStage, ContactTimeZone, and AccountIndustry—that are not implemented as a standard LOV field. For this reason, the GetListOfValues method cannot be used to return values for these fields.

Table 63 shows the fields for which LOVs are available for each object. This table also details the LOV type for the field. The LOV type determines the items available in the picklist.

Table 63. Web Services Fields for Which LOVs Are Available

Object Field Name LOV_TYPE

Account AccountType ACCOUNT_TYPE

Custom Picklist OCC_CUST_LOV_ACCOUNT_0 through OCC_CUST_LOV_ACCOUNT_99


Region TRAINING_LOC_REGION

Activity Custom Picklist OCC_CUST_LOV_ACTION_0 through OCC_CUST_LOV_ACTION_99

Asset Custom Picklist OCC_CUST_LOV_REVN_0 through OCC_CUST_LOV_REVN_99

Type PRODUCT_TYPE

Operating Status

Campaign CampaignType CAMPAIGN_TYPE

Custom Picklist OCC_CUST_LOV_CAMPAIGN_0 through OCC_CUST_LOV_CAMPAIGN_99

Status CAMPAIGN_STATE

Contact ContactType CONTACT_TYPE

Custom Picklist OCC_CUST_LOV_CONTACT_0 through OCC_CUST_LOV_CONTACT_99


MrMrs MR_MRS



Lead Country COUNTRY

Custom Picklist OCC_CUST_LOV_LEAD_0 through OCC_CUST_LOV_LEAD_99

MrMrs MR_MRS

Rating OCCAM_LEAD_RATING

Source OCCAM_LEAD_SOURCE

StateProvince STATE_ABBREV

Status OCCAM_LEAD_STATUS

Opportunity Custom Picklist OCC_CUST_LOV_OPTY_0 through OCC_CUST_LOV_OPTY_99



Probability PROB

ReasonWonLost REASON_WON_LOST

Status OPTY_STATUS

Product Status IMPL_PHASE

ProductType PROD_CD

BodyStyle AUTO_BODY_STYLE_TYPE

DoorStyle AUTO_DOORS_STYLE_TYPE

Engine AUTO_ENGINE_TYPE

Make OD_AUTO_MAKE_TYPE

Model OD_AUTO_MODEL_TYPE

Transmission AUTO_TRANSMISSION_TYPE

Trim OD_AUTO_TRIM_TYPE

Category PRODUCT_CATEGORY

PriceType UNIT_OF_MEASURE

SubType FINS_ASSET_PROD_CLASS_MLOV

TherapeuticClass THERAPEUTIC_CLASS





104

Methods CalledTable 64 details the method called by the LOV service, and its name as defined on the service.

Opportunity The opportunity object allows employees to identify and record a potential revenue-generating event that has arisen with an account or contact. Opportunities can be generated from marketing campaigns when leads indicate that they are interested in a product or service that has been offered.

Parent ServicesAccount, Campaign and Contact

Child ComponentsActivity, Contact, Lead, Product, Note and Revenue

Service Request Area SR_AREA

Cause SR_SEVERITY

Custom Picklist OCC_CUST_LOV_SR_0 through OCC_CUST_LOV_SR_99

Priority SR_PRIORITY

Source SR_SOURCE

Status SR_STATUS

Type SR_TYPE

Solution Custom Picklist OCC_CUST_LOV_SOLUTION_0 through OCC_CUST_LOV_SOLUTION_99

Publish SOLUTION_PUBLISH

Status SOLUTION_STATUS

Table 64. Methods Called by LOV Service


“GetListOfValues” on page 158 LOVGetListOfValues





Methods CalledTable 65 details the methods called by the opportunity service, and their names as defined on the service.

FieldsTable 66 details the required and read-only fields for the opportunity object.

Table 65. Methods Called by Opportunity Service


“Delete” on page 148 OpportunityDelete


“Insert” on page 149 OpportunityInsert

“InsertOrUpdate” on page 150 OpportunityInsertOrUpdate

“QueryPage” on page 151 OpportunityQueryPage

“Update” on page 156 OpportunityUpdate

Table 66. Required and Read-Only Fields for the Opportunity Object


Opportunity AccountId Required

CloseDate Required

OpportunityName Required

SalesStage Required

CreatedBy Read-only







OpportunityConcatField Read-only



106

ProductRevenue ProductRevenueId Read-only

ProductCategoryId Read-only

ProductCategory Read-only

ProductPartNumber Read-only

ProductStatus Read-only

ProductType Read-only

OpportunityId Read-only


OpportunityIntegrationID Read-only

OpportunityExternalSystemId Read-only

OpportunitySalesStage Read-only

OpportunityAccountId Read-only

OpportunityAccountName Read-only

OpportunityAccountLocation Read-only

OpportunityAccountExternalSystemId Read-only

OpportunityAccountIntegrationId Read-only



Table 66. Required and Read-Only Fields for the Opportunity Object




Table 67 details the status key for the opportunity object.

Table 67. Status Key for the Opportunity Object



CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

Activity CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

OpportunityId



108

Contact AccountId

ContactId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

OpportunityId

Lead AccountId

ContactId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

LastUpdated

LeadId

ModifiedBy

ModifiedById

ModifiedDate

OpportunityId





Table 68 details the pick map fields for the opportunity object.

OpportunityNote CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

OpportunityId

Product CreatedBy

CreatedByDate

CreatedById

ExternalId

ProductRevenueId

IntegrationID

ModifiedBy

ModifiedById

ModifiedDate

Table 68. Pick Map Fields for the Opportunity Object


Opportunity Owner OwnerId


Territory TerritoryId





110

Table 69 provides a list of the filterable fields for the child components of the opportunity objects, and a list of user key combinations for each child component. All parent fields on the opportunity object are filterable.

ProductRevenue ProductName ProductId

ProductExternalSystemId ProductId


ContactExternalSystemId ContactId


Owner OwnerId

Table 69. Filterable Fields and User Key Fields on the Opportunity Object’s Child Components


Opportunity All OpportunityId

IntegrationId

ExternalSystemId


Owner

Subject

DueDate

Priority

Status

Contact ContactType AccountName and Private

ContactFirstName ContactFirstName and ContactLastName and Private

JobTitle

ContactLastName

Owner

Id

Table 68. Pick Map Fields for the Opportunity Object




Lead Campaign

EstimatedCloseDate

Rating

Source

Status

LeadOwner

PotentialRevenue

ProductInterest

SalesPerson

LeadId

Note Subject Subject and Description

Product OpportunityIntegrationId OpportunityExternalSystemId

OpportunityExternalSystemId OpportunityIntegrationId

OpportunitySalesStage

OpportunityAccountId

OpportunityAccountName

OpportunityAccountLocation

OpportunityAccountExternalSystemId

OpportunityAccountIntegrationId

ModifiedDate

ContactId

ContactExternalSystemId


Contract

OwnerId

Owner

SerialNumber

Revenue

ExpectedRevenue

Quantity

PurchasePrice





112

Product (contd.) PurchaseDate

StartCloseDate

NumberOfPeriods

Frequency

Probability

Forecast

AssetValue

Premium

ShipDate

Status

Type

Warranty

ProductRevenue ProductRevenueId ProductRevenueId



ProductId

ProductName

ProductExternalSystemID

ProductionIntegrationId

ProductCategoryId

ProductCategory

ProductPartNumber

ProductStatus

ProductType

OpportunityId

OpportunityName





Table 70 details the list of value fields available for the opportunity object.

For more information on the fields exposed through the opportunity Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the opportunity object.

PortfolioThe portfolio object allows you to define and record details about the collection of financial services that you may provide to an account. Financial services include loans, credit cards, insurance, general banking, and so on.

NOTE: To download the Portfolio WSDL, you must be given access to the Portfolio object. If you do not have access to the Portfolio object, it will not be available to download from the Web Services Administration screen or available to use the vertical Web service calls. For assistance in gaining access to the Portfolio object, contact your Siebel CRM OnDemand service provider.


Table 70. Picklists Available for the Opportunity Object


Opportunity LeadSource OCCAM_LEAD_SOURCE


Probability PROB

ReasonWonLost REASON_WON_LOST

Status OCCAM_LEAD_STATUS

Type UT_OPPTY_TYPE

Year YEAR



Product Frequency LOV_FREQUENCY_TYPE

Probability % PROB

Status STATUS

TYPE REVENUE_TYPE

Warranty LOV_WARRANTY_TYPE

Contract LOV_CONTRACT_TYPE



114

Methods CalledTable 71 details the methods called by the portfolio service, and their names as defined on the service.

FieldsTable 72 details the read-only fields for the portfolio object and its child component.

Table 71. Methods Called by Portfolio Service


“Delete” on page 148 PortfolioDelete


“Insert” on page 149 PortfolioInsert

“InsertOrUpdate” on page 150 PortfolioInsertOrUpdate

“QueryPage” on page 151 PortfolioQueryPage

“Update” on page 156 PortfolioUpdate

Table 72. Read-Only Fields on the Portfolio Object


Portfolio PortfolioId Read-only

Owner Read-only

OwnerId Read-only

PrimaryContact Read-only




CreatedBy Read-only





Table 73 details the status key for the portfolio object.

Contact ContactId Read-only



ContactHomePhone Read-only

ContactEmail Read-only




CreatedBy Read-only



Table 73. Status Key for the Portfolio Object


Portfolio CreatedBy

CreatedById

CreatedDate

ExternalSystemId

PortfolioId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

Table 72. Read-Only Fields on the Portfolio Object




116

Table 74 details the pickmap fields for the portfolio object and its child objects.

Table 75 provides a list of the filterable fields and user key combinations for the child components of the portfolio object. All parent fields on the portfolio object are filterable.

Owners ContactId

CreatedBy

CreatedById

CreatedDate

Id

ModifiedBy

ModifiedById

ModifiedDate

Table 74. Pick Map Fields for the Portfolio Object


Portfolio InstitutionExternalId InstitutionId

InstitutionIntegrationId InstitutionId

InstitutionName InstitutionId

InstitutionLocation InstitutionId

Product ProductId





Table 75. Filterable Fields and User Key Fields on the Portfolio Object’s Child Components


Portfolio All PortfolioId

IntegrationId

ExternalSystemId

Table 73. Status Key for the Portfolio Object




Table 76 details the picklists available for the portfolio object.

For more information on the fields exposed through the portfolio Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the portfolio object.

See AlsoContact

ProductThe product object allows you to define and record details about a product or service that your company sells to its customers, including information on product price, category, and so on. The product object does not have any child objects.




ContactFirstName

ContactLastName

ContactHomePhone

ContactEmail

PrimaryInsured

NamedInsured

PolicyOwner

Relationship

Table 76. Picklists Available for the Portfolio Object


Portfolio AccountType FINS_ASS_LIAB_ALL_LIF_PLC_MLOV

Status IMPL_PHASE

TermUnit FINS_CD_INTEREST_FREQ_MLOV

Contact Relationship CC_CLSE_ACCT_LOV_CD

Table 75. Filterable Fields and User Key Fields on the Portfolio Object’s Child Components




118

Parent ServicesAccount, Campaign and Contact

Child ComponentsActivity, Contact, Lead, Product, Note and Revenue

Methods CalledTable 77 details the methods called by the product service, and their names as defined on the service.

FieldsAll fields on the product object are filterable.

Table 78 details the required and read-only fields for the product object.

Table 77. Methods Called by Product Service


“Insert” on page 149 ProductInsert


“InsertOrUpdate” on page 150 ProductInsertOrUpdate

“QueryPage” on page 151 ProductQueryPage

“Update” on page 156 ProductUpdate

Table 78. Required and Read-Only Fields for the Product Object

Field Name Type

ProductName Required

CreatedBy Read-only








Table 79 details the status key for the product object.

Table 80 details the pick map field for the product object.

Table 81 details the user keys for the product object.

Table 82 details the list of value fields available for the product object.

Table 79. Status Key for the Product Object


Product Id

IntegrationId

ModifiedById

ModifiedDate

Table 80. Pick Map Field for the Product Object


ParentCategory ParentCategoryId

Table 81. User Keys for the Product Object


Product ProductId

IntegrationId

ExternalSystemId

Table 82. List Of Values Fields Available for the Product Object

Field Name LOV Type

BodyStyle AUTO_BODY_STYLE_TYPE

Category PRODUCT_CATEGORY

Class PRODUCT_TYPE

DoorStyle AUTO_DOORS_STYLE_TYPE




120

For more information on the fields exposed through the product Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the product object.

See AlsoProduct Category

Product CategoryThe product category object allows you to logically sort products into groups, where each product is in some way related to the other products in the category. The product category object does not have any child objects.

Methods CalledTable 83 details the methods called by the product category service, and their names as defined on the service.



PriceType UNIT_OF_MEASURE

ProductType PROD_CD

Revision FINS_PROD_STATUS_VERSION_MLOV

Status IMPL_PHASE

SubType FINS_ASSET_PROD_CLASS_MLOV

TherapeuticClass THERAPEUTIC_CLASS



Table 83. Methods Called by Product Category Service


“Delete” on page 148 ProductCategoryDelete


“Insert” on page 149 ProductCategoryInsert

Table 82. List Of Values Fields Available for the Product Object

Field Name LOV Type



FieldsAll fields on the product category object are filterable.

Table 84 details the required and read-only fields for the product category object.

Table 85 details the status key for the product category object.

“InsertOrUpdate” on page 150 ProductCategoryInsertOrUpdate

“QueryPage” on page 151 ProductCategoryQueryPage

“Update” on page 156 ProductCategoryUpdate

Table 84. Required and Read-Only Fields for the Product Category Object

Field Name Type

CategoryName Required

CreatedBy Read-only




ModifiedByFullName Read-only



Table 85. Status Key for the Product Category Object


AdminProductLine Id

IntegrationId

ModifiedById

ModifiedDate

Name

Table 83. Methods Called by Product Category Service




122

Table 86 details the pick map field for the product object.

Table 87 details the user keys for the product category object.

For more information on the fields exposed through the product category Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the product category object.

See AlsoProduct

Service RequestThe service request object allows customers to request information or assistance with a problem related to products or services purchased from your company. Service requests may be ranked for severity and prioritized accordingly.

Parent ServicesAccount, Contact and Solution

Child ComponentsActivity, Solution, Audit Trail and Note

Table 86. Pick Map Field for the Product Category Object


ParentCategory ParentCategoryId

Table 87. User Keys for the Product Category Object


Product ProductCategoryId

IntegrationId

ExternaSystemId

Name



Methods CalledTable 88 details the methods called by the service request service, and their names as defined on the service.

FieldsTable 89 details the required and read-only fields for the service request object.

Table 88. Methods Called by Service Request Service


“Delete” on page 148 ServiceRequestDelete


“Insert” on page 149 ServiceRequestInsert

“InsertOrUpdate” on page 150 ServiceRequestInsertOrUpdate

“QueryPage” on page 151 ServiceRequestQueryPage

“Update” on page 156 ServiceRequestUpdate

Table 89. Required and Read-Only Fields for the Service Request Object

Field Name Type

ContactEmail Read-only




CreatedBy Read-only







ServiceRequestConcatId Read-only



124

Table 90 details the status key for the service request object.

Table 90. Status Key for the Service Request Object



ContactId

CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate

Activity CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate



Table 91 details the pick map fields for the service request object.

ServiceRequestNote CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate

ServiceRequestId

Solution CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate

Table 91. Pick Map Fields for the Service Request Object


Owner OwnerId


AssetIntegrationId AssetId

AssetExternalSystemId AssetId

ProductExternalSystemId ProductId

Table 90. Status Key for the Service Request Object




126

Table 92 provides a list of the filterable fields for the child components of the service request object, and a list of user key combinations for each child component. All parent fields on the service request object are filterable.

Table 93 details the list of value fields available for the service request object.

Table 92. Filterable Fields and User Key Fields on the Service Request Object’s Child Components

Child Component Filterable Fields User Key Field Combinations

Service Request All ServiceRequestId

IntegrationId

ExternalSystemId

SRNumber


Owner

Subject

DueDate

Priority

Status

Audit Trail Date

User

FieldModified

Service Request Note Subject Subject and Description

Solution Title Title

Published

SolutionId

Status

Id

Table 93. Picklists Available for the Service Request Object

Field Name LOV Type

Area SR_AREA

Cause SR_SEVERITY




For more information on the fields exposed through the service request Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the service request object.

SolutionThe solution object stores information on solutions to customer problems or service requests. Solutions can be reused if the same problem is identified with a product or service. This prevents duplication of work for customer service representatives.

Parent ServiceService Request

Child ComponentService Request

Methods CalledTable 94 details the methods called by the solution service, and their names as defined on the service.

Source SR_SOURCE

Status SR_STATUS

Type SR_TYPE

Table 94. Methods Called by Solution Service


“Delete” on page 148 SolutionDelete


“Insert” on page 149 SolutionInsert

“InsertOrUpdate” on page 150 SolutionInsertOrUpdate

“QueryPage” on page 151 SolutionQueryPage

“Update” on page 156 SolutionUpdate

Table 93. Picklists Available for the Service Request Object

Field Name LOV Type



128

FieldsTable 95 details the required and read-only fields for the solution object.

Table 96 details the status key for the solution object.

Table 95. Required and Read-Only Fields for the Solution Object

Field Name Type

Title Required

CreatedBy Read-only



CreatorId Read-only





Table 96. Status Key for the Solution Object


Solution CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate



Table 97 provides a list of the filterable fields for the child components of the solution objects, and a list of user key combinations for each child component. All parent fields on the solution object are filterable.

ServiceRequest CreatedBy

CreatedById

CreatedDate

ExternalSystemId

Id

IntegrationId

LastUpdated

ModifiedBy

ModifiedById

ModifiedDate

Table 97. Filterable Fields and User Key Fields on the Solution Object’s Child Components


Solution All SolutionId

IntegrationId

ExternalSystemId

Service Request Subject SRNumber

Area

Owner

Priority

Type

Cause

Source

Status

Table 96. Status Key for the Solution Object




130

Table 98 details the list of value fields available for the solution object.

For more information on the fields exposed through the solution Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the solution object.

See AlsoService Request

TerritoryThe territory object allows you to store information about the sales territory that is assigned to a user. This includes information about the territory name, a description, the currency code, and the sales quota for the territory. The territory object does not have any associated child objects, however, the territory object is a parent object and is defined in its own WSDL.

Methods CalledTable 99 details the methods called by the territory service, and their names as defined on the service.

Table 98. Picklists Available for the Solution Object

Field Name LOV Type

Area SR_AREA

Cause SR_SEVERITY


Source SR_SOURCE

Status SR_STATUS

Type SR_TYPE

Table 99. Methods Called by Territory Service


“Delete” on page 148 TerritoryDelete


“Insert” on page 149 TerritoryInsert

“InsertOrUpdate” on page 150 TerritoryInsertOrUpdate



FieldsAll fields on the territory object are filterable. The TerritoryName field is a user key for the territory object.

Table 100 details the required and read-only fields for the territory object.

Table 101 details the status key for the territory object.

“QueryPage” on page 151 TerritoryQueryPage

“Update” on page 156 TerritoryUpdate

Table 100. Required and Read-Only Fields for the Territory Object

Field Name Type

TerritoryName Required

Territory Read-only

Table 101. Status Key for the Territory Object


Territory CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

TerritoryId

Table 99. Methods Called by Territory Service




132

Table 102 details the pick map field for the territory object.

Table 103 details the list of value fields available for the territory object.

For more information on the fields exposed through the territory Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the territory object.

UserThe user object allows you to define and record details of all users in the system—for example, name, position, contact details, manager, and so on. It is different from the Current User object in that it is not restricted only to the currently logged in user. It enables queries to be run on all users of the system, and enables an administrator to insert and update a user’s profile. The user object does not have any child components.

Parent ServiceUser Group

Table 102. Pick Map Field for the Territory Object


ParentTerritoryIntegrationId ParentTerritoryId

ParentTerritoryExternalSystemId ParentTerritoryId

ParentTerritoryId ParentTerritoryId

Table 103. Picklists Available for the Territory Object

Field Name LOV Type

ParentTerritoryExternalSystemId PARENT_TERRITORY_ID

ParentTerritoryIntegrationId PARENT_TERRITORY_ID



Methods CalledTable 104 details the methods called by the user service, and their names as defined on the service.

FieldsAll fields on the user object are filterable.

Table 105 details the required and read-only fields for the user object.

Table 104. Methods Called by User Service



“Insert” on page 149 UserInsert

“InsertOrUpdate” on page 150 UserInsertOrUpdate

“QueryPage” on page 151 UserQueryPage

“Update” on page 156 UserUpdate

Table 105. Required and Read-Only Fields for the User Object

Field Name Type

FirstName Required

LastName Required


CreatedBy Read-only


LastSignInDateTime Read-only

ManagerFullName Read-only






134

Table 106 details the status key for the user object.

Table 107 details the pick map field for the user object.

Table 108 provides a list of user key combinations for the user object.

For more information on the fields exposed through the user Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the user object.

See AlsoCurrent User

Table 106. Status Key for the User Object


User EMailAddr

Id

IntegrationId

LastModified

LastModifiedByPersonId

Table 107. Pick Map Field for the User Object


Role RoleId

Table 108. User Key Fields on the User Object

Child Components User Key Field Combinations

User UserId

ExternalSystemId

IntegrationId

EmailAddr



User GroupThe User Group object allows you to create groups to which users can be added. Users can only be a member of one group, and groups can contain many users.

Child ComponentUser

Methods CalledTable 109 details the methods called by the user group service, and their names as defined on the service.

FieldsTable 110 details the required and read-only fields for the user group object.

Table 109. Methods Called by User Group Service


“Delete” on page 148 UserGroupDelete


“Insert” on page 149 UserGroupInsert

“InsertOrUpdate” on page 150 UserGroupInsertOrUpdate

“QueryPage” on page 151 UserGroupQueryPage

“Update” on page 156 UserGroupUpdate

Table 110. Required and Read-Only Fields for the User Group Object


User Group Name Required

UserGroupId Read-only

User UserGroupUserId Read-only

UserId Read-only

Alias Read-only

Email Read-only

Role Read-only





136

Table 111 details the status key for the user group object.

Table 112 details the pick map field for the user group object.

Table 111. Status Key for the User Group Object


UserGroup CreatedBy

CreatedById

CreatedDate

ModifiedBy

ModifiedById

ModifiedDate

UserGroupId

UserGroupIntegrationId

UserGroupExternalSystemId

User CreatedBy

CreatedById

CreatedDate

Members_UserId

ModifiedBy

ModifiedById

ModifiedDate


UserIntegrationId

Table 112. Pick Map Field for the User Group Object


User UserIntegrationId UserId

UserExternalSystemId UserId



Table 113 provides a list of the filterable fields for the child components of the user group object, and a list of user key combinations for each child component. All parent fields on the user group object are filterable.

For more information on the fields exposed through the user group Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the user group object.

VehicleThe vehicle object allows you to create and store information about a vehicle, for example, a car, a truck, a van, and so on, that your company would like to sell to a contact or account. This information includes the vehicle’s current mileage, the invoice price, the dealership, the make, and so on.

NOTE: To download the Vehicle WSDL, you must be given access to the Vehicle object. If you do not have access to the Vehicle object, it will not be available to download from the Web Services Administration screen or available to use the vertical Web service calls. For assistance in gaining access to the Vehicle object, contact your Siebel CRM OnDemand service provider.


Table 113. Filterable Fields and User Key Fields on the Solution Object’s Child Components


User Group All Name

User UserGroupId

UserId

UserIntegrationId


Alias

Email

Role

UserFirstName

UserLastName



138

Methods CalledTable 114 details the methods called by the vehicle service, and their names as defined on the service.

FieldsTable 115 details the required and read-only fields for the vehicle object.

Table 114. Methods Called by Vehicle Service


“Delete” on page 148 VehicleDelete


“Insert” on page 149 VehicleInsert

“InsertOrUpdate” on page 150 VehicleInsertOrUpdate

“QueryPage” on page 151 VehicleQueryPage

“Update” on page 156 VehicleUpdate

Table 115. Required and Read-Only Fields for the Vehicle Object


Vehicle VehicleId Read-only

Contact Read-only

ProductType Read-only

SellingDealer Read-only

ServicingDealer Read-only

Contact ContactId Required

ContactExternalSystemId Required

ContactIntegrationId Required



Table 116 details the status key for the vehicle object.

Table 116. Status Key for the Vehicle Object


Vehicle CreatedBy

CreatedById

CreatedDate

ExternalSystemId

IntegrationId

ModifiedBy

ModifiedById

ModifiedDate

VehicleId

Contact ContactId

CreatedBy

CreatedById

CreatedDate

ModifiedBy

ModifiedById

ModifiedDate



140

Table 117 details the pick map fields for the vehicle object.

Table 118 provides a list of the filterable fields for the child components of the vehicle object, and a list of user key combinations for each child component. All parent fields on the vehicle object are filterable.

Table 117. Pick Map Fields for the Vehicle Object


Vehicle AccountName AccountId

AccountSite AccountId


AccountExternalID AccountId

SellingDealerExternalId SellingDealerId

SellingDealerIntegrationId SellingDealerId

ServicingDealerExternalId ServicingDealerId

ServicingDealerIntegrationId ServicingDealerId

Contact ContactExternalSystemId ContactId


Table 118. Filterable Fields and User Key Fields on the Vehicle Object’s Child Components


Vehicle All VehicleId

ExternalSystemId

IntegrationId


ContactExternalSystemId ContactExternalSystemId


ContactFirstName

OnDemand Objects Exposed Through Web Services ■ Child Objects


Table 119 details the list of value fields available for the vehicle object.

For more information on the fields exposed through the vehicle Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the vehicle object.

Child ObjectsThe following is a list of the child objects that are used in Siebel OnDemand Web Services:

■ “Address” on page 142

■ “Asset” on page 142

■ “Audit Trail” on page 143

■ “Competitor” on page 143

■ “Login History” on page 143

■ “Multiple Contact Roles” on page 144

■ “Note” on page 144

Table 119. Picklists Available for the Vehicle Object

Field Name LOV Type

Body AUTO_BODY_STYLE_TYPE

Door AUTO_DOORS_STYLE_TYPE


ExteriorColor AUTO_EXTERIOR

InteriorColor AUTO_INTERIOR

Location AUTO_VEHICLE_LOC



VehicleOwnedBy AUTO_OWNED_BY

Status IMPL_PHASE



UsedNew AUTO_NEW_USED_TYPE

WarrantyType WARR_TYPE

Year YEAR



142

■ “Partner” on page 144

■ “Quota” on page 145

■ “Revenue” on page 145

■ “Related Account” on page 145

■ “Related Contact” on page 145

■ “Team” on page 146

AddressThe address object stores information on the different addresses that are associated with accounts and contacts. It is used to store billing and shipping addresses for accounts. It is also used to store personal addresses for contacts.

Parent ObjectAccount

AssetThe asset object stores information on the assets held by your accounts—for example, the products that an account has purchased. The asset object is used to manage products through their life cycle. It is also used by your accounts to register products, receive product news and literature, track warranty agreements, and receive recommendations on scheduled services.

FieldsTable 120 details the list of value fields available for the asset object.

For more information on the fields exposed through the user Web service, go to the Web Services Administration screen within the OnDemand application and generate the WSDL for the asset object.


Table 120. Picklists Available for the Asset Object

Field Name LOV Type

Type PRODUCT_TYPE



Audit TrailThe audit trail object stores information about how a service request object is modified from the moment that it created until a solution for the service request has been found. The audit trail object stores information such as the created and modified dates for the service request, and also the users that created and updated the service request.

Parent ObjectService Request

CompetitorThe competitor object in the Account interface exposes the information on competitors for your accounts.

FieldsTable 121 details the list of value fields available for the competitor object.

For more information on the competitor fields exposed, go to the Web Services Administration screen within the OnDemand application and generate the WSDL file.


Login HistoryThe login history object stores information about currently logged in user such as the amount of times that the user has logged in, and the dates and times on which the current user logged in.

Parent ObjectCurrent User

Table 121. Picklists Available for the Competitor Object

Field Name LOV Type

RelationshipRole PARTY_REL_TYPE

ReverseRelationshipRole PARTY_REL_TYPE



144

Multiple Contact RolesThe multiple contact roles object stores information on the different roles that a contact can hold within an account. It stores information on the different types of jobs that one contact can hold within your organization. For example, the customer relations manager may also have a role within the sales team to provide valuable feedback the sales representatives.

Parent ObjectsAccount

NoteThe note object stores extra information (as a note) on a parent object. This allows employees who are working on a particular record to add extra information as they see fit. For example, when talking to a contact, an employee may notice that the contact is not happy with a service provided. The employee may record this in a note so that any other employees who talk to the contact are aware of the contact’s dissatisfaction.

Parent ObjectsAccount, Campaign, Contact, Opportunity and Service Request

PartnerThe partner object in the Account interface exposes the information on partners for your accounts.

FieldsTable 122 details the list of value fields available for the partner object.

For more information on the partner fields exposed, go to the Web Services Administration screen within the OnDemand application and generate the WSDL file.


Table 122. Picklists Available for the Partner Object

Field Name LOV Type

RelationshipRole PARTY_REL_TYPE

ReverseRelationshipRole PARTY_REL_TYPE



QuotaThe quota object stores information about the sales targets of, and sales made by the current user.

Parent ObjectCurrent User

Related AccountThe related account object stores information on an account that has a relationship with the parent account in question. The details of the related account child object are inherited from a particular account parent object.


Related ContactThe related contact object stores information on an contact that has a relationship with the parent contact in question. The details of the related contact child object are inherited from a particular contact parent object.

Parent ObjectContact

RevenueThe revenue object stores monetary information about accounts, contacts and their associated opportunities. This includes information on the revenue available, expected revenue, and also information about the products associated with the accounts, contacts and opportunities, and so on.

Parent ObjectAccount, Contact and Opportunity



146

TeamThe team object stores information on the team that is assigned to a particular account or contact. In this way, a team of employees can be dedicated to an account or contact, ensuring that the activities, service requests, leads, and opportunities surrounding that account or contact are always kept up-to-date and are attended to regularly.

Parent ObjectAccount and Contact


5 Web Services OnDemand API Calls

There are a number of methods that can be invoked by the OnDemand objects. For each object, the methods are defined in the WSDL for that object. Many of the methods described in this chapter can call all of the objects.

The methods invoked by the OnDemand objects are used to insert, update, and find data within a specified OnDemand instance. The following sections detail the methods that may be called on the OnDemand objects. For each of these methods, the description, usage, arguments taken, and return values are detailed.

This chapter has the following sections:

■ “API Calls”

■ “Service API Calls” on page 157

API CallsThe OnDemand Web Services’ core methods are listed in Table 123. The core methods consist of those methods that may be called on the OnDemand objects — for example, Account, Contact, Opportunity, and so on.

Table 123. Web Services OnDemand Core Methods

Method Name Comments

Delete Uses input XML objects to find records in the Siebel OnDemand database that match specified field values, and then deletes them (in other words, puts them into the Recycle Bin).

NOTE: To conform with OnDemand’s business logic, be careful about the order in which objects are deleted. You cannot delete some objects unless some action is performed on its child objects. For example, you cannot delete an account unless all its service requests are associated with a different account.

Insert Inserts a new record to the OnDemand database.

InsertOrUpdate Updates an existing record or inserts a new record if one did not exist for this instance of the object.

QueryPage Executes a query against a specified list of records, and returns a subset of the records that match the search criteria set by the method arguments.

Update Updates the selected record with the new value.


Web Services OnDemand API Calls ■ API Calls

148

DeleteRemoves the record of the specified object from the OnDemand database.

UsageYou use the delete method to remove one or more records of a particular object from an OnDemand instance.

Table 124 illustrates the behavior of the delete method on child objects related to the parent object being deleted. For details on deleting a specific child from a parent level object, see “Update” on page 156.

Table 124. Behavior of Delete Method on Child Objects

Parent Object ChildAction When Parent Is Deleted

Account Activity Delete

Asset None

Competitor None

Contact None

Lead Delete

Note Delete

Opportunity Delete

Partner None

ServiceRequest None

Team None

Campaign Activity Delete

Contact None

Lead Delete

Note Delete

Opportunity Delete

Contact Activity None

Lead Delete

Note Delete

Opportunity None

ServiceRequest None

Lead Activity Delete



ArgumentsTable 125 documents the arguments taken by the delete method.

Return Value of the CallThe status key for each of the deleted objects.

See AlsoUpdate.

InsertInserts a new record in the OnDemand database.

Opportunity Activity Delete

Contact None

Lead Delete

Note Delete

ServiceRequest Activity Delete

AuditTrail None

Note None

Solution Not Specified

Solution ServiceRequest None

Table 125. Arguments Taken by the Delete Method

Name Description Required Default I/O

ListOf(Object). For example, ListOfAccount

The list of object instances to be deleted.

Yes Not applicable

I/O

Table 124. Behavior of Delete Method on Child Objects

Parent Object ChildAction When Parent Is Deleted



150

UsageYou use the insert object to create one or more records of a particular object from an OnDemand instance. Each of the objects (both child and parent level) provided in the input argument must provide data in at least one of the user keys for the given object. The user key information is used to uniquely identify records. If no user key values are provided, or if there is a conflict with the user keys of an existing record, the insert method will fail, and a SOAP error will be thrown by the API.

When inserting a batch of records, the batch is treated as a single transaction. If one record fails to insert during a batch insertion, the entire operation is rolled back and no records are inserted.

ArgumentsTable 126 documents the arguments taken by the insert method.

Return Value of the CallThe status key for each of the OnDemand objects.

See AlsoUpdate.

InsertOrUpdateUpdates an existing record or inserts a new record if one did not exist for this instance of the object.

UsageYou use the InsertOrUpdate method to update one or more records of a particular object in an OnDemand instance. Each of the objects (both child and parent level) provided in the input argument must provide data in at least one of the user keys for the given object. Use the user key information to uniquely identify records. If no user key values are provided or if there is a conflict with the user keys of an existing record, the insert method fails, and a SOAP error is thrown by the API.

Use the user key specified for the parent level objects in the input argument to determine whether to insert each of the parent records, or to update an existing parent record.

Table 126. Arguments Taken by the Insert Method



The list of object instances to be inserted.

Yes Not applicable

I/O



Table 127 outlines how the delete method acts upon parent and child objects to create or update an object instance.

ArgumentsTable 128 documents the arguments taken by the InsertOrUpdate method.

Return Value of the CallThe status key for each of the inserted or updated objects.

See AlsoUpdate

Insert

QueryPageExecutes a query against a specified list of records, and returns a subset of the records that match the search criteria set by the method arguments. You can use the QueryPage method in a number of different ways to return records, which means that there are a number of functions that can be performed using this method. For example, it is possible to query by example, by template, or by children. For more information, see “Querying OnDemand Data Using Web Services” on page 153 and Appendix A, “OnDemand XML API Samples.”

Table 127. Effect of InsetOrUpdate on Parent and Child Objects

Method Name New Parent New ChildExisting Parent

Child Exists in OnDemand and in Input

Child Exists in OnDemand but Not in Input

InsertOrUpdate New parent New child Update parent

Update child Child is unchanged

Table 128. Arguments Taken by the InsertOrUpdate Method



The object instance to be inserted or updated.

Yes Not available I/O



152

UsageThis method is useful when the search specification retrieves a large number of records at the root component. To avoid returning one huge set of results, you can specify the number of records to be returned using the PageSize argument. You can also use the StartRowNum method argument to dictate which records are to be returned.

Even though the QueryPage method returns a limited number of records, it keeps the data in the cache, which you can then retrieve by calling the QueryPage method again with a new value for the StartRowNum method argument.

For all OnDemand object methods, it is possible to query, update, or insert using one operation within a parent-child relationship. This type of query is called QueryByChildren. The query can be assembled using parent attributes as well as child attributes. You can query for all children of a particular parent or set of parents, all parents of a particular child or set of children, or for both parents and children of a particular set. The QueryByChildren method uses the same expression notation as QueryByExample, where the expression may appear in either the parent, the child, or both. These queries are described in Appendix A, “OnDemand XML API Samples.”

NOTE: If you want to include a field to be returned in a query’s results, you must include a blank tag in the QueryPage input. Effectively, this means that you must set the field’s value to “”, that is, an empty string.

About OnDemand Query SyntaxOnly fields that have nonempty values are interpreted as part of the search specification. Table 129 illustrates how the field values follow the syntax shown. Nonterminal symbols are in italics.

Table 129. Query by Example Syntax

Syntax Type Syntax

conjunction OR

conjunction AND

expression IS NULL

expression operator value

expression ( expression ) conjunction ( expression )

literal literalChar literal

literalChar ''

literalChar {0x00 ... 0xFF} \ '

literalChar literal Œ

operator =

operator ~=

operator <



OnDemand Query Syntax RulesSyntax rules are as follows:

■ Literal data is always enclosed in single quotes.

■ If you want to use a single quote within a literal, you must place another single quote immediately beside the quote that you want to specify as a literal. In this way, the query recognizes the quote as a literal and not as an operator. For example, the string ab'c is presented as ab''c.

■ In order to use the wildcard characters asterisk (*), question mark (?), and backslash (\) in queries, they must be preceded by the backslash (\) character. For example, if you want to use the ? wildcard operator in a query, you must precede it with the backslash character as follows:

\?

■ Every expression must start with an operator to avoid ambiguity. There is no default operator.

■ Wildcard characters are treated as such only in the context of the operator LIKE.

■ To find a match for a value that has no value, the IS NULL expression must be specified as the QBE field's value.

■ The tilde (~) and equal (=) ~= operator denotes a case-insensitive exact search (no wildcards used), while the ~LIKE operator denotes a case-insensitive wildcard search.

■ A conjugated expression must be enclosed in parentheses to avoid ambiguity. However, nonconjugated expressions must not be enclosed in parentheses.

Querying OnDemand Data Using Web ServicesThe QueryPage functions require a list of object instances as input in order to perform a query. This input parameter is called ListOf(Object). For example, the ContactQueryPage method requires the ListOfContact parameter. Each ListOf(Object) parameter requires at least one instance of the Object in order to specify a valid query.

To query an object by a certain field, specify the Query by Example expression that corresponds to the desired result. For information about Query by Example expression samples, see Table 137.

operator <=

operator >

operator >=

operator <>

operator LIKE

operator ~LIKE

value 'literal'

Table 129. Query by Example Syntax

Syntax Type Syntax



154

Querying Multiple FieldsIf you want to query multiple fields, Query by Example expressions must be present in each of the fields. When multiple fields in an object instance have Query by Example expressions, the QueryPage method result is the intersection of all the Query by Example expressions, or in other words, all of the Query by Example expressions are combined using the AND operator. This is outlined in “Example 1: Combining Expressions Using the AND Operator.”

Example 1: Combining Expressions Using the AND OperatorThe Web service client requires the first name, last name, and job title of all the contacts in OnDemand that have a job title equal to CEO and a last name equal to Doe. The XML representation of the ListOfContact object that must be sent in the ContactQueryPage call is as follows:

<ListOfContact>

<Contact>

<JobTitle>= ‘CEO’</JobTitle>

<ContactLastName>='Doe'</ContactLastName>

<ContactFirstName />

</Contact>

</ListOfContact>

Multiple Query by Example Expressions on a Single FieldIf you want to apply multiple Query by Example expressions to a single field, you can combine each Query by Example expression using either the AND or the OR operator. The result is either the intersection or the union of the object instances respectively.

NOTE: For multiple Query by Example expressions on a single field, each Query by Example expression must be enclosed in brackets.

Example 2: Combining Multiple Expressions Using the AND OperatorThe Web service client requires the first name, last name, and job title of all the contacts that have been updated between July 28, 2004 6:30am and July 28, 2004 6:45 am.

Send the following XML representation of the ListOfContact object in the ContactQueryPage call:

<ListOfContact>

<Contact>

<JobTitle />

<ContactLastName />




<LastUpdated> (>='07/28/2004 06:30:00') AND (<='07/28/2004 06:45:00')</LastUpdated >

</Contact>

</ListOfContact>

Example 3: Combining Multiple Expressions Using the OR OperatorThe Web service client requires the first name, last name, and job title of all the contacts in OnDemand that have a last name equal to Doe or Brown.

Send the following XML representation of the ListOfContact object in the ContactQueryPage call:

<ListOfContact>

<Contact>

<JobTitle />

<ContactLastName>(='Doe') OR (=’Brown’)</ContactLastName>


</Contact>

</ListOfContact>

ArgumentsTable 130 documents the arguments taken by the QueryPage method.

Table 130. Arguments Taken by the QueryPage Method



The list of object instances queried (input), and after query execution, the list of object instances returned (output).

Yes Not applicable

I/O

PageSize The maximum number of records displayed on a page following a query.

No 10 I



156

Return Value of the CallAn object or list of objects of the type on which the method was called.

LastPage: A Boolean value that indicates whether or not the last value in the query set has been returned.

UpdateUpdates the selected record with the new value.

UsageYou use the update method to update one or more records of a particular object in an OnDemand instance. Each of the objects (both child and parent level) provided in the input argument must provide data in at least one of the user keys for the given object. You use the user key information to uniquely identify records. If no user key values are provided, or if there is a conflict with the user keys of an existing record, the insert method will fail, and a SOAP error is thrown by the API.

StartRowNum Indicates the row from which the QueryPage method starts to return records. Use the StartRowNum parameter to return a set of records for any given method.

For example, if you want to return records 1-100, you set the StartRowNum parameter to 1. Then, if you want to return records 101-200, you set StartRowNum to 101, and run the query again. You continue doing this until the last page is returned. This way, you can return all records for a particular query.

No 0 I

UseChildAnd If this parameter is set to TRUE, then the query result set returns the set of fields that are common to both parent and child components. (That is, the query set returned is the AND combination of parent and child fields).

If this parameter is set to FALSE (or not set at all), then the query result set returns the set of fields that are common to either the parent component or the child component. (That is, the query set returned is the OR combination of parent and child fields).

No FALSE I

Table 130. Arguments Taken by the QueryPage Method


Web Services OnDemand API Calls ■ Service API Calls


Table 131 outlines how the update method acts upon parent and child objects to update an object instance.

ArgumentsTable 132 documents the arguments taken by the update method.

Return Value of the CallThe updated object.

Service API CallsThe OnDemand Web Services’ service methods are listed in Table 133. The service methods consist of those methods that are not called on OnDemand objects. Instead they are used to carry out functions that enable external applications to establish an interface with the OnDemand GUI.

Table 131. Effect of Update on Parent and Child Objects

Method Name New Parent New ChildExisting Parent

Child Exists in OnDemand and in Input

Child Exists in OnDemand but Not in Input

Update Error New child Update parent

Update child Child is removed

Table 132. Arguments Taken by the Update Method



The object instance to be updated. Yes Not applicable

I/O

Table 133. Web Services OnDemand Service Methods

Method Name Comments

“GetListOfValues” on page 158

Gets a lists of values from external applications and presents them to OnDemand end users.

“GetMapping” on page 159

Gets a list of the display names of fields for a particular service and their associated XML tags.

“SetPasswordAPI” on page 159

Sets the passwords of users that use the application.



158

GetListOfValuesGets a list of values from external applications and presents them to OnDemand end users.

UsageThis method is used to enable external applications to present lists of values to end users, typically in a language-dependent manner.

Because OnDemand Web Services is language-independent, it is the client application’s responsibility to convert code from language-independent code (LIC) used by OnDemand to language-dependent values (LDVs) typically used by the external presentation layer.

The returned list of values corresponds to the organization to which the current end user (that is, the user whose credentials have been passed during the log-in call) belongs.

NOTE: You can use this method for getting the list of values allowed for customized picklist fields—for example, in querying LOV type OCC_CUST_LOV_ACCOUNT_0 to get a list of values for the field with XML tag CustomPickList0 in the Account Web Service.

For examples of LOV Service elements, see “LOV Service Element Sample” on page 170.

ArgumentsTable 134 documents the arguments taken by the GetListOfValues method.

Table 134. Arguments Taken by the GetListOfValues Method


LOVType List of value types to be queried. Yes Not applicable

I

LanguageCode Code of the language in which language-dependent values are to be returned—for example, ENU, DEU, FRA, ESN, and so on. If not specified, the default language for the current session’s end user is used.

No User’s Default Language

I

ListOfLOV A sequence of LOV elements that represent individual values and contain the following subelements:

■ Language

■ LIC (Language Independent Code)

■ Type

■ LDV (Language Dependent Value)

Yes Not applicable

O



Return Value of the CallListOfLOV: A list of values from an external application.

GetMappingReturns the display names and XML tags of the fields of a named Web service or one of its child components.

UsageThis method is used to return the display names of all the fields in a particular Web service. It also returns the XML tags for each field. It, therefore, displays the mappings between the display names of fields and their XML tags.

This method can be used on all Web services and on all of their child components.

ArgumentsTable 135 documents the arguments taken by the GetListOfValues method.

Return Value of the CallA list of the display names for fields and their associated XML mappings.

SetPasswordAPIAllows the system administrator to set the passwords of users that use the application.

UsageThis method is used to enable external applications to synchronize user passwords. For security reasons the password API is not available by default. If a customer wishes to use SetPasswordAPI, they can call Customer Care to have the functionality enabled.

The API allows for the setting of passwords for one or more users at the same time. For each password that is updated, a corresponding user Audit Trail record is created. A user with the ability to set passwords does not have the ability to update the password of another user that has the ability to set passwords.

Table 135. Arguments Taken by the GetMapping Method


ObjectName The name of the object for which you wish to return a list of mappings.

Yes NA I



160

Table 136 details the arguments taken by SetPasswordAPI.

Table 136. Arguments Taken by SetPasswordAPI

Field Name Type

UserId Read-only

UserExternalId Read-only

UserIntegrationID Read-only

UserEmail Read-only

Password Create/Read/Update/Delete


A OnDemand XML API Samples

This appendix displays samples of XML code generated by OnDemand, and it contains the following sections:

■ “Query by Example Expression Samples”

■ “Query by Template Samples” on page 164

■ “Query by Children Samples” on page 165

■ “LOV Service Element Sample” on page 170

Query by Example Expression SamplesThe examples in this section cover the corner cases of quote and wildcard escaping. Assume that a table in the OnDemand database contains the following values for a particular column that is being queried by example:

abcabcd'abc'= 'abc'abc?dabc*daBc*Dabcdabc*dabc\dabc\*dabc\\*dabc\dabc\*'dabc\?"dabc\*"dabc\*'"d(NULL value)


OnDemand XML API Samples ■ Query by Example Expression Samples

162

Table 137 specifies the returned record sets for various values of each Query by Example field value that maps to the preceding list.

Table 137. Returned Record Sets

QBE Field Value Returned Record Set Comments

abc N/A An unquoted value without an explicit operator is invalid input.

'abc' N/A A quoted value without an explicit operator is invalid input.

= '''abc ''''abc'

= "'abc'" N/A Double quotes are not allowed by OnDemand Query Validator. Consequently, this example returns an error message.

= 'abc 'abc

= '= ''abc '''= 'abc'

= '= 'abc'' N/A The caller is responsible for correctly formatting quotes in Query* methods. This example does not have correctly formatted quotes, so it results in an error.

= 'abc?d 'abc?d

= 'abc\?d 'abc?d

LIKE 'abc\?d 'abc?d

LIKE 'abc?d 'abc?dabc*dabc\d

~LIKE 'abc?d 'abc?daBc*Dabc*dabc\d

= 'abc*d' abc*d An wildcard character that has not been formatted with quotes is treated as if it were formatted with quotes.

= 'abc\*d 'abc*d

= 'abc\\*d 'abc\*d

OnDemand XML API Samples ■ Query by Example Expression Samples


LIKE 'abc\\*d 'abc\dabc\*dabc\\*dabc\dabc\*'dabc\?"dabc\*"dabc\*'"d

= 'abc\\\*"d 'abc\*"d

= 'abc\\?"d 'abc\?"d

= 'abc\\\?"d 'abc\*"d

LIKE 'abc\\?"d 'abc\?"dabc\*"d

LIKE 'abc\\\?"d 'abc\?"d

LIKE 'abc\\*"d 'abc\?"dabc\*"dabc\*'"d

LIKE 'abc\\\*"d 'abc\*"d

= 'abc\\\*''d 'abc\*'d

~ LIKE 'abc*\d 'aBc*Dabc*dabcdabc*d

LIKE 'abc*\d 'abc*dabcdabc*d

(empty field) N/A An empty field value does not influence the search specification in Query by Template.

IS NULL (empty field)(( > 'abc*' )AND ( < 'abcd' ))

OR (~= 'abc*d') abc*daBc*Dabc*d

NOT LIKE 'abc?d' N/A OnDemand Query Validator does not support the NOT operator, so this query returns an error.

> 'abc' BUT < 'abcd' N/A BUT is not a valid conjunction. Consequently, this query returns an error.

Table 137. Returned Record Sets

QBE Field Value Returned Record Set Comments


OnDemand XML API Samples ■ Query by Template Samples

164

Query by Template SamplesThe OnDemand Export API has Query by Template semantics. This means that only components and fields that are present in the input parameter are present in the output parameter.

Query by Template Example 1The following is an example of an input integration object instance:

<ListOfAccount>

<Account>

<LastUpdated>>= '10/13/2003 03:25:32'</LastUpdated>

<Name />

<Location>IS NULL</Location>

</Account

</ListOfAccount>

The search specification that the system applies to the Account BusComp is as follows:

[LastUpdated] >= '10/13/2003 03:25:32' AND [Location] IS NULL.

The following shows an example of the XML returned:

<ListOfAccount>

<Account>

<LastUpdated>10/14/2003 04:25:32</LastUpdated>

<Name>IBM</Name>

<Location></Location>

</Account>

<Account>

<LastUpdated>10/13/2003 03:25:36 PM</LastUpdated>

<Name>Siebel</Name>


</Account>

</ListOfAccount>

OnDemand XML API Samples ■ Query by Children Samples


Query by Template Example 2The following is an example of an input integration object instance:

<ListOfAccount>

<Account>

<LastUpdated/>

<Name>LIKE 'Sie*'<Name/>

<Location>= 'San Mateo'</Location>

</Account>

</ListOfAccount>

The system applies the search specification as follows:

[Name] LIKE 'Sie*' AND [Location] = 'San Mateo'

The following is an example of the XML returned:

<ListOfAccount>

<Account>

<LastUpdated>10/19/2003 09:22:33 AM</LastUpdated>

<Name>Siebel Systems, Inc.</Name>

<Location>San Mateo</Location>

</Account>

<Account>

<LastUpdated>8/22/2003 03:25:36 PM</LastUpdated>

<Name>Siemens</Name>

<Location>San Mateo</Location>

</Account>

</ListOfAccount>

Query by Children SamplesThe examples in this section illustrate the semantics of queries that include search specifications on child components.



166

Query by Children Example 1This example illustrates data synchronization through periodic exports based on the time of the last update:

<ListOfAccount>

<Account>

<Name></Name>


<LastUpdated>(> '05/12/02 10:00:03 PM') AND (<= '05/18/02 10:02:22 PM')</LastUpdated>

<ListOfContact>

<Contact>

FirstName><FirstName>

<LastName></Lastname>


</Contact>

</ListOfContact>

<ListOfBusinessAddress>

<BusinessAddress>

<Address/>

<City/><State/>

<ZipCode/>


<BusinessAddress>

</ListOfBusinessAddress>

</Account>

</ListOfAccount>

Using a formal search specification language, the system interprets this query as follows:

(([Account_LastUpdated] > '05/12/02 10:00:03 PM')

AND

([Account_LastUpdated] <= '05/18/02 10:02:22 PM')



)

OR

EXISTS

(

([Contact_LastUpdated] >= '05/12/02 10:00:03 PM')

AND

([Contact_LastUpdated] <= '05/18/02 10:02:22 PM')

)

OR

EXISTS

(

([BusinessAddress_LastUpdated] > '05/12/02 10:00:03 PM')

AND

([BusinessAddress_LastUpdated] <= '05/18/02 10:02:22 PM')

)

This tells the system to find all accounts that have met one of the following conditions between 05/12/02 10:00:03 PM and 05/18/02 10:02:22 PM in the current user's time zone that have:

■ Been updated

■ Been associated with at least one new contact

■ Changed or added at least one business address

Query by Children Example 2This example shows how to query to find all child opportunities associated with a contact:

<ListOfOpportunity>

<Opportunity>

<Description/>

<Revenue></Revenue>

<ListOfContact>

<Contact>

<Id>(= '12-12345') OR (= '12-54321')</Id>

<FirstName></FirstName>



168

<LastName></Lastname>

</Contact>

</ListOfContact>

</Opportunity>

</ListOfOpportunity>

Using a formal search specification language, the system interprets this query as follows:

EXISTS( [Contact_Id]='12-12345' OR [Contact_Id]='12-54321' )

This tells the system to find all opportunities that are associated either with a contact whose Id is 12-12345, or with a contact whose Id is 12-54321.

Query by Children Example 3This example illustrates the interpretation of peer inter-component and intra-component expressions, and the fact that the default operator for text fields is LIKE:

<ListOfAccount>

<Account>

<Name></Name>


<LastUpdated>> 05/12/02 10:00:03 PM</LastUpdated>

<ListOfContact>

<Contact>

<FirstName>= 'Sanjin'<FirstName>

<LastName>= 'Tulac'</Lastname>

<MiddleName />

</Contact>

<Contact>

<FirstName>LIKE 'Alex*'<FirstName>

<LastName>LIKE 'Warsha*'</Lastname>

</Contact>

</ListOfContact>

<ListOfOpportunity>

<Opportunity>



<Description/>

<Revenue>>= '10000'</Revenue>

</Opportunity>

</ListOfOpportunity>

</Account>

</ListOfAccount>

The system interprets this input to the QueryPage method as the following search specification:

[Account_LastUpdated] >= '05/12/02 10:00:03 PM'

OR

EXISTS

(

(

([Contact_FirstName]='Sanjin') AND ([Contact_LastName]='Tulac')

)

OR

(

([Contact_FirstName]LIKE 'Alex*') AND [Contact_LastName]LIKE 'Warsha*')

)

)

OR

EXISTS

(

[Opportunity_Revenue] >= '10000'

)

This tells the system to find all accounts that meet one of the following conditions:

■ Have been updated since 05/12/02 10:00:03 PM in current user's time zone

■ Are associated with a contact whose first name is Sanjin and whose last name is Tulac

■ Are associated with a contact whose first name starts with Alex and whose last name starts with Warsha

■ Have an associated opportunity whose revenue is estimated at more than 10000 units of currency


OnDemand XML API Samples ■ LOV Service Element Sample

170

LOV Service Element SampleThe following is a sample of the ListOfLOV XML element:

<ListOfLOV>

<LOV>

<Language>ENU</Language>

<LIC>Competitor</LIC>

<Type>ACCOUNT_TYPE</Type>

<LDV>Competitor</LDV>

</LOV>

<LOV>


<LIC>Customer</LIC>


<LDV>Customer</LDV>

</LOV>

<LOV>


<LIC>Partner</LIC>


<LDV>Partner</LDV>

</LOV>

</ListOfLOV>


Index

Aaccess

locale-dependent access 18Account interface

competitor object 143partner object 144

account objectabout 34child components 34fields 35fields, do not use 48filterable fields 41methods 34pick map fields 40picklists 47read-only fields 35required fields 35status key 36

activity objectabout 48child components 49fields 49filterable fields 53list of values 54methods 49parents 49pick map fields 52read-only fields 49required fields 49status key 50usage 48user key fields 53

API callscore methods 147Delete method 148GetListOfValues 158GetMapping 159Insert method 149InsertOrUpdate method 150QueryPage method 151Service API calls 157SetPasswordAPI 159Update method 156

asset child object 142audit fields 17audit trail object 143

CC# code sample 30campaign object

about 54child components 55fields 55filterable fields 58list of values 60methods 55parents 55pick map field 58read-only fields 55required fields 55status key 56

child componentsaccount 34activity 49campaign 55contact 60, 98current user 73CustomObject1 75CustomObject2 83household 93opportunity 104, 118portfolio 113service request 122solution 127user group 135vehicle 137

child objectsasset 142audit trail 143competitor 143login history 143multiple contact roles 144note 144partner 144quota 145related account 145related contact 145revenue 145team 146

client integrationsexamples 10

code samplesC# code sample 30Java code sample 26


Index ■ D

172

logging in/off 23VB code sample 24

company-specific WSDL 17competitor object

about 143fields 143

contact objectabout 60child components 60, 98fields 61filterable fields 67list of values 72methods 61objects not to use 73parents 60pick map 66read-only fields 61required fields 61status key 62

core methodsDelete method 148GetListOfValues 158GetMapping 159Insert method 149InsertOrUpdate method 150list of 147QueryPage method 151Service API calls 157SetPasswordAPI 159Update method 156

core technologiesabout 9

Currency and Number fields 18current user object

about 73child components 73fields 74filterable fields 74methods 73read-only fields 74required fields 74

custom fields 17customization-specific WSDL 17CustomObject1 object

about 75child components 75fields 75filterable fields 81, 89list of values 82methods 75pick map 79read-only fields 75required fields 75status key 77

user keys 81, 89CustomObject2 object

about 83child components 83fields 84list of values 91methods 83pick map 87read-only fields 84required fields 84status key 85

DDate and Time fields 18dealer object

about 91fields 92methods 91pick map field 92read-only fields 92required fields 92status key 92

Delete methodarguments 149usage 148

Ffeatures, what’s new 7field types

custom fields 17supported 18

fieldsaudit 17custom fields 17read-only, account object 35read-only, activity object 49read-only, campaign object 55read-only, contact object 61read-only, current user object 74read-only, CustomObject1 object 75read-only, CustomObject2 object 84read-only, dealer object 92read-only, household object 95read-only, lead object 98read-only, opportunity object 105read-only, portfolio object 114read-only, product category object 121read-only, product object 118read-only, service request object 123read-only, solution object 128read-only, territory object 131read-only, user group object 135read-only, user object 133

Index ■ G


read-only, vehicle object 138required, account object 35required, activity object 49required, campaign object 55required, contact object 61required, current user object 74required, CustomObject1 object 75required, CustomObject2 object 84required, dealer object 92required, household object 95required, lead object 98required, opportunity object 105required, product category object 121required, product object 118required, service request object 123required, solution object 128required, territory object 131required, user group object 135required, user object 133required, vehicle object 138

Ggenerating customized WSDL 17GetListOfValues 158GetListOfValues method

call return value 159GetMapping 159GetMapping method

arguments 158call return value 159

Hhousehold object

about 93child components 93fields 95filterable fields 97list of values 93, 97methods 94pick map field 97read-only fields 95required fields 95status key 96

IInsert method

arguments 150call return value 150usage 149

InsertOrUpdate methodarguments 151call return value 151parent and child objects, effect on 151

usage 150integration tag, viewing 17integrations

client integration examples 10XML API session, integration requests 21

JJava code sample 26

Kkeys

status key, about 16status key, account object 36status key, activity object 50status key, campaign object 56status key, contact object 62status key, CustomObject1 object 77status key, CustomObject2 object 85status key, dealer object 92status key, household object 96status key, lead object 99status key, opportunity object 107status key, product category object 121status key, product object 115, 119status key, service request object 124status key, solution object 128status key, territory object 131status key, user group object 136status key, user object 134status key, vehicle object 139user key, about 15user key, product category object 122user key, product object 119user key, user object 134

Llead object

about 98fields 98filterable fields 101methods 98parents 98pick map fields 100picklists 101read-only fields 98required fields 98status key 99

locale-dependent access 18login history child object 143LOV object

about 102methods 104

LOV service element sample 170


Index ■ M

174

Mmethods

OnDemand objects, called by 15parent and child objects, behavior of 15

methods called byaccount 34activity 49campaign 55contact 61current user 73CustomObject1 75CustomObject2 83dealer 91household 94lead 98LOV 104opportunity 105portfolio 114product 118product category 120service request 123solution 127territory 130user 133user group 135vehicle 138

multiple contact roles child object 144

Nnew features 7note child object 144Number and Currency fields 18

Oobjects

OnDemand objects, methods called by 15OnDemand parent and child objects 12parent and child objects, behavior of

methods 15parent and child relationships, about 14pick maps 16status keys 16user keys 15

objects, exposedSee parent objects; child objects

OnDemandcustom fields 17integration tag 17

OnDemand Web Services 10communication with (figure) 9OnDemand objects, methods called by 15OnDemand parent and child objects 12parent and child objects, behavior of

methods 15parent and child relationships, about 14pick maps 16status keys 16user keys 15XML API Reliability 12XML API Security 11

opportunity objectabout 104child components 104, 118fields 105filterable fields 110list of value fields 113methods 105parents 104pick map field 109read-only fields 105required fields 105status key 107

Pparent and child objects

about and list of 12InsertOrUpdate method, effect on 151methods, behavior of 15relationships, about 14Update method, effect of 157

parent objectsaccount 34activity 48campaign object 54contact object 60current user 73dealer 91household object 93lead 98list of 33LOV 102opportunity 104portfolio 113product 117product category 120service request 122solution 127territory 130user 132user group 135vehicle 137

parent servicesactivity 49campaign 55contact 60lead 98

Index ■ Q


opportunity 104product 118service request 122solution 127user 132

partner objectabout 144fields 144

pick mapaccount object 40activity object 52campaign object 58contact CustomObject1 79contact CustomObject2 87contact object 66dealer object 92household object 97lead object pick map fields 100OnDemand pick maps, about 16opportunity object 109portfolio object 116product category object 122product object 119service request object 125user group object 136user object 132, 134vehicle object 140

portfolio objectabout 113child components 113fields 114filterable fields 116list of values 117methods 114pick map fields 116read-only fields 114user key fields 116

product category objectabout 120fields 121methods 120pick map field 122read-only fields 121required fields 121status key 121user keys 122

product objectabout 117fields 118methods 118parents 118pick map field 119picklists 119read-only fields 118

required fields 118status key 115, 119user keys 119

Qquery by children samples

example 1 165example 2 167example 3 168

query by example expression samples 161query by template samples

example 1 164example 2 165

QueryPage methodabout 151arguments 155call return value 156OnDemand query syntax, about 152querying data using Web Services 153usage 152

quota object 145

Rread-only fields

account object 35activity object 49campaign object 55contact object 61current user object 74CustomObject1 object 75CustomObject2 object 84dealer object 92household object 95lead object 98opportunity object 105portfolio object 114product category object 121product object 118service request object 123solution object 128territory object 131user group object 135user object 133vehicle object 138

related account object 145related contact object 145release, what’s new 7reliability

XML API Reliability 12required fields

account object 35activity object 49campaign object 55


Index ■ S

176

contact object 61current user object 74CustomObject1 object 75CustomObject2 object 84dealer object 92household object 95lead object 98opportunity object 105product category object 121product object 118service request object 123solution object 128territory object 131user group object 135user object 133vehicle object 138

revenue object 145

Ssecurity

XML API Security 11Service API calls

core methods 157GetListOfValues 158GetMapping 159SetPasswordAPI 159

service request objectabout 122child components 122fields 123filterable fields 126methods 123parents 122pick map 125picklists 126read-only fields 123required fields 123status key 124

SetPasswordAPI 159setting up

C# code sample 30Java code sample 26logging in/off code samples 23process of 19VB code sample 24XML API session limits 22XML API session, establishing and

managing 19XML API session, integration requests 21XML API session, logging in 20XML API session, logging off 21

Siebel OnDemand Web Services Toolkitabout 9

OnDemand Web Services 10solution object

about 127child components 127fields 128filterable fields 129list of value fields 130methods 127parents 127read-only fields 128required fields 128status key 128

status keyabout 16account object 36activity object 50campaign object 56contact object 62CustomObject1 object 77CustomObject2 object 85dealer object 92household object 96lead object 99opportunity object 107product category object 121product object 115, 119service request object 124solution object 128territory object 131user group object 136user object 134vehicle object 139

Tteam object 146territory object

about 130fields 131methods 130picklists 132read-only fields 131required fields 131status key 131

Time and Date fields 18

UUpdate method

arguments 157call return value 157parent and child objects, effect of 157usage 156

user group objectabout 135

Index ■ V


child components 135fields 135, 138filterable fields 137methods 135pick map field 136read-only fields 135required fields 135status key 136

user keysabout 15product category object 122product object 119user object 134

user objectabout 132fields 133methods 133parents 132pick map field 132, 134read-only fields 133required fields 133status key 134user keys 134

VVB code sample 24vehicle object

about 137child components 137filterable fields 140methods 138pick map field 140picklists 141

read-only fields 138required fields 138status key 139

WWeb services

custom fields 17integration tag 17

Web Services ToolkitSee Siebel OnDemand Web Services Toolkit

WSDL, generating company-specific 17

XXML API Reliability 12XML API samples

LOV service element sample 170query by children samples 165query by example expression samples 161query by template samples 164

XML API Security 11XML API session

establishing and managing 19integration requests 21logging in 20logging off 21maximum objects in Web Services

request 23maximum records returned 23number of sessions limit 22request rate limit 22request size limit 23session timeouts 23


Index ■ X

178

Documents

OnDemand Web Services