2Overview of Using the Siebel REST API
Overview of Using the Siebel REST API
This chapter provides an overview of the Siebel CRM Representational State Transfer (REST) application programming interface (API). It includes the following topics:
About Siebel CRM REST API
REST (Representational State Transfer) is a software architecture style that provides a convenient and consistent approach to requesting and modifying data. In the Siebel CRM RESTful system, resources are stored on the Siebel Server; a client sends a request using an HTTP verb (such as GET, POST, PUT, or DELETE) that the Siebel Server perform a particular action (such as querying, inserting, upserting, or deleting a Siebel CRM resource), and the Siebel Server performs the action and sends a response.
The Siebel REST API is provided with the Siebel Application Interface installation. For more information about installing Siebel Application Interface, see Siebel Installation Guide for Microsoft Windows. The Siebel REST API is enabled by configuring and deploying a Siebel Application Interface profile. The Siebel Application Interface profile can be deployed to multiple Siebel Application Interface nodes.
The Siebel REST API exposes Siebel Business Objects, Siebel Business Services, and Siebel Repository Objects. For more information about Siebel Business Objects, Siebel Business Services, and Siebel Repository Objects, see Configuring Siebel Business Applications.
The following are aspects of the Siebel REST API that are aligned with general best practices of REST APIs:
-
A base URI to access Siebel Server resources, for example:
http://Server Name:port/Siebel/v1.0/
Support for JSON resource representations.
Support for XML resource representations.
Operations on Siebel CRM resources are mapped to semantically similar HTTP methods, such as GET, PUT, POST, and DELETE.
Hypertext links to Siebel CRM Child Business Components in the case of the Data API resources in the REST API response.
Support for Outbound to interact with other Cloud applications that communicate through REST.
About Siebel CRM REST API Architecture
The Siebel CRM REST API services are deployed as a WAR file (siebel-rest.war) on the Siebel Application Interface. The Siebel Application Interface is a java-based Web component that runs on the Tomcat server. The Siebel Application Interface provides the Web entry point to Siebel Business Application services. The Siebel Application Interface interacts with the Siebel Server and Gateway Server to manage and fulfill Siebel REST requests.
Each Siebel Enterprise can have multiple Siebel Application Interface nodes and can have multiple Siebel Servers but can have only one Gateway Server. Installations of Siebel Enterprise Server and Siebel Application Interface modules include deployment of WAR files into the application container and configuration of application container ports.
The Siebel application configurations are managed by the Siebel Management Console and stored in the Siebel Gateway Server.
The preceding figure shows the high-level architecture of Siebel REST within the Siebel Application Interface.
Requests: Users send an application request to the Siebel Application Interface. Siebel Application Interface requests include: UI, EAI, or REST. The appropriate application channel accepts the request. Application channels include: UI Channel, EAI Channel, or REST Channel.
Siebel Application Interface: The Siebel Application Interface serves as the Web server for the Siebel Business Applications. The Siebel Application Interface identifies requests for Siebel application data coming from Web clients and flags these requests for routing to a Siebel Server. When information is sent from the Siebel Server back to the Web client, the Siebel Application Interface helps complete the composition of the Web page for forwarding to the client.
Siebel Management Console: The Siebel Management Console is a Web-based application that allows users to configure various Siebel Application components and save the configurations in the Siebel Gateway Server.
REST Channel: The REST channel is one of three application channels that provide an endpoint responsible for receiving and processing user requests. The REST Channel is responsible for serving the REST requests. Other application channels include the UI channel and EAI channel.
Siebel Server: Siebel Server functions as an application server and is composed of server components.
Gateway Server: Siebel Gateway provides the dynamic address registry for Siebel Servers and server components, and also for Siebel Application Interface. The Siebel Application Interface configurations are also stored and managed in the Gateway Server.
Outbound Channel: The outbound channel forwards requests to external Web services.
For more information, see Siebel Installation Guide for the operating system you are using, Siebel Deployment Planning Guide, and Siebel System Administration Guide.
About Siebel CRM REST API Requests and Responses
A request can include the following information:
A request URI. For more information about URI formats, see About Siebel CRM REST API URI Formats.
The request URI contains the base URI signifying what category of Siebel resources to invoke. Siebel resources include: Business Objects, Repository Objects, and Business Services.
The request URI contains the object type of the invoked Siebel CRM resource. For example, Account Business Component under Account Business Object. For more information about the supported Siebel CRM resources, About Siebel CRM REST API Supported Resources.
The HTTP method that you use to perform a REST API operation (query, insert, upsert, or delete) on the Siebel CRM Server. For more information about supported HTTP methods, see About Supported HTTP Methods.
Header information to define the parameters of the interaction with the Siebel CRM Server and the information and format you want in the response. For more information about supported HTTP headers, see About Supported HTTP Header Fields.
After the Siebel CRM Server processes the request, the server sends back a response in JSON or XML format based on the requested content type. The response body contains the results of the REST API call and also additional information based on what was specified in the request.
The response can include the following information:
A HTTP status code that indicates whether the request was successful or failed. For more information about HTTP status codes, see About Standard HTTP Status Codes and Error Messages.
A list of Siebel proprietary field and value pairs.
If the request failed, then the response body includes additional information about the error. For additional information about HTTP error status codes, see About Standard HTTP Status Codes and Error Messages.
Hypertext links to Siebel CRM child resources, in the REST API response, such as links to Child Business Components in the case of the Data API. For more information about links, see About Siebel CRM REST API Response Links.
About Siebel CRM REST API URI Formats
The Siebel CRM REST API exposes Siebel CRM Business Objects, Business Services, and Repository Objects.
Siebel CRM REST API executes resource requests for each resource category using the following HTTP URI formats:
-
Siebel CRM REST API basic URI for Siebel Business Objects:
https://Server Name:port/Siebel/v1.0/data/
-
Siebel CRM REST API basic URI for Siebel Business Services:
https://Server Name:port/Siebel/v1.0/service/
-
Siebel CRM REST API URI for a Siebel Repository resource:
https://ServerName:port/Siebel/v1.0/workspace/<your workspace name>/
Where:
Server Name:port: Indicates the name of the server and port hosting the Siebel REST API services.
siebel: Indicates the product name for the REST API.
version: Indicates the current version number, 1.0, of the REST API.
data: Indicates the requested resource is a Siebel Business Object. For more information about Siebel Business Objects, see Configuring Siebel Business Applications.
service: Indicates the request resource is a Siebel Business Service. For more information about Siebel Business Services, see Configuring Siebel Business Applications.
workspace: Indicates the request resource is Siebel Repository Data. For more information about workspaces, see Using Siebel Tools. For more information about Siebel Repository Objects, see Configuring Siebel Business Applications.
<your workspace name>: Indicates the name of your repository workspace.
About URI Parameters
When constructing a URI, there are a number of optional parameters available to manage response results. Some parameters are described in the following table.
Table URI Parameters
| Parameter | Description |
|---|---|
PageSize |
Used only for the GET operation. The PageSize parameter is the integer that tells the Siebel Server how many records to return. If you query for all the Siebel contacts whose last name starts with the letter A and you do not want to get too many records (for performance reasons), then you can restrict the number of records returned. You restrict the number of records returned by setting the PageSize parameter to a reasonable number. The default value is 10. If you do not set a value for this parameter, then query will return only 10 records. All records that match the search criteria are returned. For example, PageSize=20 returns only twenty contact records, even if more exist in the Siebel database. If fewer records exist that match that search criteria, then all records are returned (but no more than twenty).
Note: It is recommended that you retrieve the lowest number of records required for any one call. The more records that are returned, the larger the message and the slower the response. The maximum number of records cannot exceed 100.
|
StartRowNum |
Used only for the GET operation. The StartRowNum parameter is used when there is a need to start returning records at a specific row. For example, StartRowNum=100 starts at row 100 of the record set. The first number in a record set is zero, therefore, this request starts at record 99 (given you start counting from one for the first record). The default value and returns the records from beginning. This parameter is useful for paging through a record set N records at a time. For example, if there are 100 records in a record set, but you want to retrieve only ten at a time, then enter StartRowNum=0 and PageSize=10 on the first call, then StartRowNum=10 on the next call, then StartRowNum=20 on the next call, and so on. |
fields |
Used for only GET or Query operations to specify a comma-separated list of property names (fields) that are required in the REST API response. The response contains only the files given in this list irrespective of fields available in the source being queried. |
searchspec |
Used to include search specifications in the REST API response. |
ViewMode |
Used as an access control that controls users access to data and application functionality. Values include:
For more information about access controls, see About Access Controls for Siebel Business Component REST Requests. |
childlinks |
Used for only GET or Query operations to specify a comma-separated list of child business components that require links returned in the REST API response. The response returns only links to child objects specified in this parameter value. For an example of childlinks, see Querying for a Siebel CRM Repository Resource That Returns Child Links Only for Lists. |
uniformresponse |
Used for only GET or Query operations to specify a consistent interface to the consumers and enable them to use a single parser for responses of requests of similar type. The response returns one or more records wrapped in an array. It is passed as a query parameter with a case insensitive value for the flag as y or Yes. For example, URI: For examples of |
The syntax for using URI parameters is the parameter name followed by an equal sign (=) with the value of the parameter, and each parameter is separated from other parameters by an ampersand (&). For example, if you want to set the PageSize parameter to 100 and the StartRowNum parameter to 0 (zero), then you enter: Pagesize=100&StartRowNum=0
About Siebel CRM REST API Supported Resources
A REST API resource is a piece of information, such as a data record or a collection of records. Each Siebel CRM REST API resource is identified by a named URI, and it is accessed using standard HTTP methods. For more information about URI formats, see About Siebel CRM REST API URI Formats. For more information about standard HTTP methods, see About Supported HTTP Methods.
The Siebel CRM REST API supports the following Siebel resources and collections:
Siebel Business Service methods that have been configured for Siebel REST API access for users with a given Siebel Responsibility. For more information about configuring Siebel Business Services, see Configuring Business Service Methods for RESTful Access.
Siebel Repository Object Types and Siebel Repository Object Instances. All repository objects that are supported for access through workspaces are accessible through the Siebel Repository REST API. Before you begin, a Workspace has to be created before performing any repository operations and the name of the workspace has be mentioned in the REST API requests. To determine if a repository object is workspace-enabled see the section on editing workspace-enabled repository objects in Using Siebel Tools.
Siebel Business Component records. The Siebel Business Components under the following Siebel Business Objects are available through the Siebel REST API:
Access Group
Account
Action
Asset Management
Campaign
Catalog
Contact
Correspondence
Employee
Expense
Fund
Household
Incentive Compensation Plan
Internal Product
List Mgmt
Offer
Opportunity
Order Entry
Payments
Position
Price List
Project
Proposal
Quote
Service Agreement
Service Request
Solution
Territory Management
Time Sheet
Usage Pattern Tracking
About Supported HTTP Methods
The following table contains the HTTP methods supported by the Siebel REST API and the corresponding Siebel CRM operation.
Table Supported HTTP Methods
| HTTP Verb | Siebel Operation | Description |
|---|---|---|
GET |
Query |
The GET method retrieves a Siebel CRM resource. |
POST |
Insert |
The POST method creates a new Siebel CRM resource. |
PUT |
Upsert |
The PUT method upserts a Siebel CRM resource. |
DELETE |
Delete |
The DELETE method deletes a Siebel CRM resource. |
About Supported HTTP Header Fields
Certain HTTP header fields define the operating parameters of the REST API transaction with Siebel CRM.
The following table contains the HTTP header fields supported by the Siebel REST API.
Table Supported HTTP Header Fields
| HTTP Header Field Name | Description | Example |
|---|---|---|
Authorization |
The HTTP request header field that indicates the type of authorization. Options include:
|
Authorization: Basic |
Content-Type |
The HTTP request and response header field that indicates the content type of the message body. Content-Type decides the format of response for all requests. The Siebel REST API supports JSON and XML encoding for the request body. The default value is application/JSON. The Content-Type field is used with POST, PUT, and GET requests. When submitting a POST or PUT request, you typically supply a body with the request. You can indicate the format of the response by setting the HTTP Content-Type header on the request. For GET requests, the content type is used to determine the format of response, either XML or JSON. |
Content-Type: application/json |
About Standard HTTP Status Codes and Error Messages
Siebel CRM REST API uses standard HTTP status codes to indicate the success or failure of API calls. When an error occurs or when a response is successful, the response header contains an HTTP code and the response body usually contains a message accompanying the HTTP response code with additional information about the error.
The following table contains the standard HTTP status codes used by the Siebel REST API.
Table Standard HTTP Status Codes and Error Messages
| HTTP Code | Message | Description |
|---|---|---|
200 |
OK |
The request successfully executed and the response has content. |
204 |
No Content |
The request successfully executed, but the content is not available. For example, the content was deleted. |
401 |
Unauthorized |
The request did not have valid authorization credentials. |
404 |
Not Found |
The requested resource was not found because of an invalid object name. |
405 |
Not Allowed |
The request is not allowed. |
406 |
Not Acceptable |
The resource identified by the request is capable of generating only response entities that have content characteristics that are not acceptable according to the accept headers sent in the request. |
415 |
Unsupported Media Type |
The data format of the request body, specified in the Content-Type header, is not supported by the targeted resource. |
500 |
Internal Server Error |
The server encountered an unexpected error, preventing it from fulfilling the request. |
About Siebel CRM REST API Response Links
A link in the Siebel CRM REST API response contains a location of a resource and metadata about that resource.
The Siebel CRM REST API response can include the following types of links:
self link. The original URL that generated the response.
canonical link. The URL for the same resource as the top-level resource. If you are already viewing the resource as a top-level resource, then this URL is the same as self. If this resource is not available as a top-level resource, then this link shows child resource context.
parent link. The URL for the parent resource details. This URL of the parent resource is returned in the response only when retrieving details about a child resource.
child link. The URL for the child resource details. The URL returns the path to retrieve each child collection for this record. The href attribute contains the child type. A response can return several child links.
association link. The URL of a specific resource included in the response. There can be many association links.
Each Siebel CRM REST API response link can include the following types of attributes:
rel. Indicates the relationship of the linked resource to the current resource that contains the list of links. Values include: Self, Parent, Child, and Canonical.
href. Indicates the fully qualified location URL of the linked resource.
About User Authentication
Siebel CRM supports the following mechanisms that the client uses to authentication user credentials:
Basic authentication over SSL. This is User ID and Password based authentication. The Base64 encoded value of the User ID and Password must be included in the Authorization header.
OAuth user using OAuth 2.0. For more information about OAuth 2.0, see About Configuring OAuth 2.0 for Authentication.
SSO, which can be either:
Pre-existing SSO mechanisms used for Siebel Applications or EAI.
SAML based SSO mechanisms. This is Identity Provider-Initiated Single Sign-On Authentication. For more information, see Siebel Security Guide.
Authentication parameters are configured in the Siebel Application Interface Profile. For information about REST Inbound Authentication parameters, see Configuring REST Inbound Authentication Parameters. For information about configuring the Siebel Application Interface Profile, see Siebel Installation Guide for Microsoft Windows.
About Configuring OAuth 2.0 for Authentication
The Siebel REST API can use the OAuth 2.0 protocol for authentication to securely identify applications before connecting to the Siebel Server.
In general, the Siebel REST API layer contacts the OAuth server over a secure channel (for example, HTTPS) to validate the access token received or obtain additional token information. The Siebel Server only requires a USERID to establish a Siebel Server session since authentication takes place outside of Siebel Server in either SSO or OAuth, and does not require a password.
The following prerequisites are required on the Siebel side before configuring OAuth for authentication. You must install and set up the components, including OAuth components, to suit your own business needs. Consult the supporting documentation of your chosen components (for example, Oracle Access Manager and Oracle API Gateway) for more information.
The Siebel Object Manager must be configured for SSO when OAuth is enabled for authentication. The related security adapter is also required. In SSO mode, when used with a custom security adapter, the specified value is passed as the password parameter to a custom security adapter if the value corresponds to the value of the TrustToken parameter defined for the custom security adapter. For more information about configuring SSO, see Siebel Security Guide.
The Siebel REST API layer contacts the OAuth server over a secure channel to validate or get token information. To enable HTTPS, the required certificates from the OAuth server must be installed in the environment where the Siebel REST API is hosted.
The following parameters must be set in the Siebel Application Interface profile:
SingleSignOn. The SingleSignOn property must be set to TRUE to implement SSO.
Authentication Type. The Authentication Type property must be set to OAuth to implement OAuth authentication
Trust Token. The Trust Token value must be the same as the security adapter TrustToken parameter value.
Authentication URL. The Authentication URL value is the URL of the OAuth Service Provider end point for Access Token validation.
Secure Channel. Set this parameter only when you have already imported the Authentication URL’s CA certificate into the Application Interface truststore. Deselect this check box when the Authentication URL’s CA certificate is not available in the Application Interface truststore. In this case, the Application Interface trusts all certificates while calling the Authentication URL over HTTPS. Oracle does not recommend this.
While the customer authentication flows vary depending on your business needs, Oracle supports all OAuth 2.0 authentication flows. This topic contains a few sample authentication flows. In all authentication flows, the Siebel REST API layer extracts and validates the Access Token when the authentication type value is OAuth. Customers must generate the authorization and access code. The Siebel Server handles only the resource server initiated flow and any remaining flows must be implemented by the customer.
Client Credentials Grant Authentication Flow
The client credentials grant flow represents an application that calls another application or service, without end user intervention. In this example, the client server application makes a call to the Siebel resource server to request business information. Since there is no end user intervention, the client is pre-authorized to have access to the resource.
The following figure is an example of the Client Credentials Grant Authentication Flow.
The steps in client credentials grant authentication flow process shown in the preceding figure are:
The business client application makes a call to the Siebel Server to request some business information by passing an access token. Since there is no end user intervention, the client is pre-authorized to have access to the resource.
The request is redirected to the OAuth server for authentication.
The OAuth server returns an access token.
The client server sends a request to the resource server. The request includes the access token in the HTTP header. Siebel Server looks for the USERID from the token to establish a Siebel Server session.
The Siebel Server validates the access token with the OAuth server.
If the access token is authorized by the OAuth server, then access is granted to the Siebel resource.
The Siebel Server returns the requested resource.
Web Server Authentication Flow
In the Web server authentication flow, the client application is running on the client server. In this case, an end user accesses an application, which needs to fetch data from a resource server on behalf of the end user, but without the end user providing his credentials to the application. The user has to provide his consent for the client application to access resources in the resource server. In this use case, all the code resides in the client server and it is not visible to the end user. For the OAuth server, you can use Oracle Access Manager and Oracle Webgate, or any other Web application and gateway depending on your business needs.
The following figure is an example of the Web server Authentication Flow.
The steps in Web Server Authentication Flow process shown in the preceding figure are:
A user initiates a request to the client application.
The request is redirected to the OAuth server (for example, Oracle Access Manager) for authentication.
The OAuth server sends a login form to the user to grant access.
The user enters their credentials and the OAuth server determines whether to grant access.
The OAuth server determines if user consent is required.
If user consent is the required, the OAuth server sends a consent form to the user.
The client server grants access.
If access is granted, the OAuth server sends an authorization code.
The client application requests an access token from the OAuth server.
The OAuth server sends the access token.
The client application sends a request to the resource server and includes the access token in the request header.
The resource server sends a request to the OAuth server to validate the access token.
The OAuth server validates the access token.
The resource server sends a response with the requested information to the client application.
The client application sends the requested information to the user.
About REST Outbound
Siebel CRM supports outbound REST communications for on-premises or cloud applications, allowing the external applications to interact with other on-premises or cloud applications that communicate through REST APIs.
Siebel outbound REST functionality is built on SOAP Outbound functionality and allows Siebel CRM to call any external endpoint that provides a valid Open API or SWAGGER compliant schema.
Siebel outbound REST functionality leverages Siebel Tools to import the REST contract and create the required metadata, such as business services or integration objects. For more information about Siebel Tools, see Using Siebel Tools.
To use REST Outbound in Siebel CRM:
Create a new outbound Web Service based on an OpenAPI compiant JSON file. For information about creating an Outbound Web Service based on an OpenAPI compliant JSON file, see Creating an Outbound Web Service Based on an Open APICompliant JSON File.
Once you have successfully imported the schema in Siebel Tools, open the Siebel Application and navigate to the Administration - Web Services screen and then to the Outbound REST Services screen. Verify the newly imported artifacts are all present in the Outbound REST Services, Service Params, and Operations applets. Make sure you configure the exact endpoint URL in the Address column of the Service Params Applet.
Create a 64-bit Java Subsystem. For more information about creating a 64-bit Java Subsystem, see Transports and Interfaces: Siebel Enterprise Application Integration.
Configure any new Siebel Business Services for RESTful access. For more information, see Configuring Business Service Methods for RESTful Access.
Configure new Siebel Business Services by associating a responsibility with a business service to control access to the business service and its methods. For more information, see Siebel Security Guide.
Setting up the proxy for external endpoint access. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.
Configure external REST endpoints. For external REST endpoints, the following parameters must be added in the Input PropertySet:
isExternalURL: true
Setting the isExternal parameter value to true removes the body keyword in the POST request body.
isEnclosedArray: true
If the whole POST body has to be enclosed in any array, then set the isEnclosedArray parameter to true.
methodValue: <value>
For path templating, add a value for the methodValue parameter. Path templating is the use of curly braces ({}) to mark a section of a URL path as replaceable.
About Getting the Siebel REST API Specification in the Open API 2.0 Standard Using Describe
Siebel REST APIs use the OpenAPI Specification (formerly the Swagger Specification) to define formats for REST requests and responses to the Siebel REST API servers.
You can use the OpenAPI Specification Describe URI parameter to provide addition metadata information in the REST API response and request. The describe parameter returns a JSON object that contains the attributes, actions, and links defined in the REST resource definition.
The describe parameter allows you to discover additional metadata on the following:
Siebel Business Objects. The Siebel Business Objects catalog contains a list of all Business Objects exposed as Base Integration Objects. The following is an example of a Siebel Business Objects URL request with a describe parameter: host-name/siebel/v1.0/data/describe
Siebel Business Services. The Siebel Business Services catalog contains list of all Siebel Business Service names, methods defined for business services, and links to each business service. The following is an example of a Siebel Business Services URL request with a describe parameter: host-name/siebel/v1.0/service/describe
Siebel Repository Objects. The Siebel Repository Objects catalog contains lists of all repository types and catalog links to their children. The following is an example of a Siebel Repository Objects URL request with a describe parameter: host-name/siebel/v1.0/workspace/main/describe
In the response, pagination is implemented for a list of Business Objects, a list of Repository Objects, and a list of Business Services but not for the associated children.
The following table contains the OpenAPI Objects supported by the Siebel REST API.
Table Open API Objects supported by the Siebel REST API
| Field Name | Description |
|---|---|
swagger |
Required. Specifies the Swagger Specification version being used. |
info |
Required. Provides metadata about the API. |
schemes object |
The transfer protocol of the API. Values MUST be from the list: "http", "https", "ws", "wss". If the schemes is not included, the default scheme to be used is the one used to access the Swagger definition itself. |
securityDefinitions |
Security scheme definitions that can be used across the specification. |
externalDocs |
Additional external documentation. |
host |
The host (name or ip) serving the API. This must be the host only and does not include the scheme nor sub-paths. It MAY include a port. If the host is not included, the host serving the documentation is to be used (including the port). The host does not support path templating. |
basePath |
The base path on which the API is served, which is relative to the host. If it is not included, the API is served directly under the host. The value MUST start with a leading slash (/). The basePath does not support path templating. |
definitions |
An object to hold data types produced and consumed by operations. |
tags |
A list of tags used by the specification with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the Operation Object must be declared. The tags that are not declared may be organized randomly or based on the tools' logic. Each tag name in the list must be unique. |
paths |
Required. The available paths and operations for the REST API. |
security |
A declaration of which security schemes are applied for the API as a whole. |
parameters |
A list of the parameters for the endpoint. |
responses |
A lists of the responses from the REST API request. |
About Access Controls for Siebel Business Component REST Requests
Access Controls refer to the set of Siebel Business Applications mechanisms that control users access to data and application functionality. For more information about access controls, see Siebel Security Guide.
Siebel implements access controls for business component data by using the ViewMode query parameter. The business component ViewMode query parameter defines the access control for a business component in a view and decides which users can access what portion of the data. The following fields in the BusComp View Modes list in Siebel Tools determine allowable visibility for a business component. For more information about View Mode, see Siebel Security Guide.
Owner Type. This field specifies the party type, with one exception (described in the following list), that is used to determine whether a user is associated with a record. This field value specifies the owner of the records in the current view mode. The allowable owner types are:
Person. The access control can be based on the user's Person record.
Position. The access control can be based on the position of the user.
Organization. The access control can be based on the organization of the user, as determined by the organization to which the user's current position belongs.
Group. The access control can be based on membership in access groups that have access to particular catalogs and categories.
Catalog Category. Catalog Category is not a party type. Access can be restricted to all of the data in all of the categories across catalogs to which the user has access. This data includes data in public categories and data in private categories to which the user's access groups have access. The user sees a flat (uncategorized) list of data.
Name. The name typically suggests the view mode.
Personal. This name is typically used when Owner type is Person.
Sales Rep. This name is typically used when Owner type is Position.
Organization. This name is typically used when Owner type is Organization.
Group. This name is typically used when Owner type is Group.
Catalog. This name is typically used when Owner type is Catalog.
You can only use access controls for Siebel REST API GET requests. You can use an access control by adding ViewMode= to your REST API GET request URL. The URL format is same for both JSON and XML REST requests. The ViewMode query parameter used in the URL is case sensitive. If the ViewMode query parameter is not specified in the URL, by default ViewMode=Sales Rep is used. ViewMode=All is not supported for REST requests.
You can use the ViewMode query parameter on the following:
Siebel Business Objects. The Siebel Business Objects catalog contains a list of all Business Objects exposed as Base Integration Objects. The following is an example of a Siebel Business Objects URL request with a ViewMode query parameter:
host-name/siebel/v1.0/data/Account/Account/?ViewMode="Sales Rep"
Siebel Repository Objects. The Siebel Repository Objects catalog contains lists of all repository types and catalog links to their children. The following is an example of a Siebel Repository Objects URL request with a ViewMode query parameter:
host-name/siebel/v1.0/workspace/MyWorkspace/Applet/SIS Account List Applet?ViewMode="Personal"