Overview of Generated Repository Integration Objects

About Integration Components

The following figure shows the Integration Objects pane. This lists the new integration object Req2SwaggerPetstoreUPOpenAPI30:body. The Integration Components pane shows the root integration component called ReqBody and its associated integration components:

Root Integration component called ReqBody
A Child Integration component to ReqBody called pet is generated. This is the actual object mapping in the JSON file.
There will also be a few Integration Component User Property elements generated for each Integration Component, such as format, required, Content-Type, type, isarray which are used for validation and runtime functionality.
Child objects called category
An array called photoUrls
An array called tags

Arrays of simple and complex objects within a complex object are represented as integration components, which are located within the root integration component of the integration object. For example the array called photoUrls is a string array, and is represented as an integration component under Req2SwaggerPetstoreUPOpenAPI30:body.

The surrounding text describes the integration components listed in the Integration Objects pane.

After performing the import, the complex object ReqBody/Pet, has the following properties:

id
name
status

The surrounding text describes the integration component user properties listed in the Integration Components pane.

In the above example, the integration object Req1SwaggerPetstoreUPOpenAPI30:body has the root integration component ReqBody which represents the wrapper to hold the actual request body for different content-type under content in the JSON file for operations such as put, post, patch and delete. If the data represented is different for each content-type inside content under the requestBody in the JSON file, then there would be multiple integration components created to represent each content-type. The content-type represented under content is identified from the user property created for the integration component named as Content-Type and the value as the actual content-type given in the JSON file, for example application/json (in the above example). As of this release, only application/json, application/*, and */* content-type are supported. Hence, repository object, only for those content types, is generated during import, and any unsupported content types are ignored.

The naming convention for the root integration component is as follows: ReqBody. In this instance, the integration object is called Req1SwaggerPetstoreUPOpenAPI30:body, therefore the value of the integration object serial number is 1. The root integration component ReqBody is a placeholder, and it has no significance in the input provided at runtime. In addition, the integration object Req1SwaggerPetstoreUPOpenAPI30:body has the root integration component ReqBody with the integration component fields:

id
name
status

Note: If the JSON file does not specify the data types clearly, then it would be defaulted to String / DTYPE_TEXT while creating the Business Service Arguments / Integration Fields. For number data type in JSON file, if format is not specified, then it will be defaulted to double. For integer data type in JSON file, if the format is not specified, then it will be defaulted to integer (int32).

The following figure shows the newly created integration component fields for the integration object Req2SwaggerPetstoreUPOpenAPI30:body.

The surrounding text describes the integration component fields listed in the Integration Components pane.

About Integration Component Response Arguments

Response arguments are prepared according to the specification of the responses under each path in the JSON file and corresponding operation or verb (such as get, put, post, delete, and patch) combination in the OpenAPI file, and the response structure is defined for each response with a valid schema.

In the Swagger Petstore 3.0 example, the business service method getOrderById:get has a defined response schema for responses when the return code is 200. For the

Swagger Petstore
                    3.0

example, the import creates the following items:

An output argument called: Res200:res
The following figure indicates an output argument called: Res8SwaggerPetstoreUPOpenAPI30:res, and its data type is Integration Object.
A response integration object.

This has a root integration component for the response code, in this example, Res200.
A child integration component defining the response body as RespBody.

This is located under the root integration component.
A child integration component indicating the response header as RespHeader.

The following figure shows the response integration object called Res9SwaggerPetstoreUPOpenAPI30:res and its Root integration components Respdefault, and child integration component as RespBody and RespHeader. The response in this example (as shown below as RespBody) is user, and is displayed in the Comments field. It is the actual response received from the outbound call.

If user is a non-array type, then its content is placed under RespBody.
If user is an array of users, then each user is wrapped under RespBody. All RespBody integration components are then placed under ListOfRespBody, and ListOfRespBody is placed under Respdefault.

The response body integration component contains fields as specified in the OpenAPI definition. The following figure shows these integration component fields:

email
firstName
id
lastName
password
phone
userStatus
username

The surrounding text describes the integration component fields.

Note: If the JSON specification has no schema referenced under response code, then no response integration object is created. Also, at runtime, the JSON response is generically converted to a property set, and is returned to the caller.

Using the SiebelHierInput Parameter in a Request

If you want to allow additional integration objects or integration component wrappers in your request body, you can use the SiebelHierInput parameter. This is used in scenarios where you want to pass the output of other Siebel business services as an input to the Siebel REST Outbound service. In these cases there can be additional wrappers of type integration object or integration component provided in request body. Another possibility is a request that contains a single object type, provided as an array type, with the prefix ListOf. Alternatively, undefined integration components are provided in the integration object along with other valid defined integration component types. In these scenarios, you can set the SiebelHierInput parameter in the input, and specify the values Y, yes, or TRUE to intelligently interpret the request, as per the repository definition.

The XML example below shows an example of an input property set with additional and undefined elements, using the SiebelHierInput parameter. The following considerations apply:

<Invalid_Wrapper>. This is an additional wrapper.
<Undefined_IO_or_wrapper>. Another type of additional undefined wrapper.
<ListOfIO6SwaggerPetstore2>.An integration object which is defined in the repository.
<undefined>. This is another undefined wrapper used around a valid integration component category. <undefined_type> is skipped, and <category> is picked for processing.
<ListOftags>. The <ListOf> wrapper is undefined because tags is an object not an array. The first object located immediately after it is processed by the Outbound service.

<?xml version="1.0" encoding="UTF-8"?>
<?Siebel-Property-Set EscapeNames="true"?>
<PropertySet  password_clnsecurity="password" username_clnsecurity="username" type_clnsecurity="basic" SiebelHierInput="true">
	<Invalid_Wrapper> 
		<Undefined_IO_or_wrapper> 
		</Undefined_IO_or_wrapper>
		<ListOfIO6SwaggerPetstore2> 
			<RootIC6 status="available" name="dog" id="1">
				<undefined_type>					
                                  <category name="canine" id="2"></category>
				</undefined_type>
				
				<ListOftags> 
					<tags name="tage1" id="2"></tags>
					<tags name="tage2" id="3"></tags>
				</ListOftags>
				
				<ListOfphotoUrls>
					<photoUrls elem__value="url1"></photoUrls>
					<photoUrls elem__value="url2"></photoUrls>
				</ListOfphotoUrls>
			</RootIC6>
		</ListOfIO6SwaggerPetstore2>
	</Invalid_Wrapper>
</PropertySet>

Based on this example, a sample JSON is as follows:

{
   "category":{
      "name":"canine",
      "id":2
   },
   "tags":{
      "name":"tag1",
      "id":2
   },
   "photoUrls":[
      "url1",
      "url2"
   ]
}

The second XML example below shows an example of an input property set with additional and undefined elements such as SiebelMessage, ListofWrappers, and uses the SiebelHierInput parameter. The following considerations apply:

<SiebelMessage>. This is an additional wrapper.
<ListOfIO1TestPushCustomers>.An integration object.
<ListOfPerson>. The <ListOf> wrapper is undefined because Person is an object not an array. The first object located immediately after it is processed by the Outbound service.
<ListOfName>. The <ListOf> wrapper is undefined because UserName is an object not array. The first object located immediately after it is processed by the Outbound service.

<?xml version="1.0" encoding="UTF-8"?>
<?Siebel-Property-Set EscapeNames="true"?>
<PropertySet
 SiebelHierInput="y"
 password_clnsecurity="123"
 username_clnsecurity="asd"
 type_clnsecurity="basic">
    	<SiebelMessage      
     	MessageId="88-4JVO0"
     	MessageType="Integration Object"
     	IntObjectName="IO1TestPushCustomers"
    	 IntObjectFormat="Siebel Hierarchical">
        		<ListOfIO1TestPushCustomers> 
            			<RootIC1>
                			<ListOfPerson> 
                   				 <Person
                     				PersonId=""
                     				bookingId=""
                     				AddressId="">
                        					<ListOfUserName>
                           						 <UserName
                             						GivenName=""
                             						Surname="">
                            						</UserName>
                        					</ListOfUserName>
                    				</Person>
                			</ListOfPerson>
            			</RootIC1>
        		</ListOfIO1TestPushCustomers>
    </SiebelMessage>
</PropertySet>

Using the disableURLEncoding Parameter in a Request

If you want to disable default outbound URL encoding, you can use the disableURLEncoding parameter. This is used in scenarios where you want to provide a full or partially encoded outbound URL to make an outbound call without the REST Outbound framework encoding this URL. You can avoid double encoding by setting the value of the disableURLEncoding parameter to true.

Note: This disables default encoding of all elements of the URL including path and query parameters.

Consider the following XML example:

<?xml version="1.0" encoding="UTF-8"?><?Siebel-Property-Set
EscapeNames="true"?><PropertySet
 childlinks_clnquery="ADD2021%2F12"
 account_undkey_clnpath="ADD2021%2F12"
 disableURLEncoding="true"
 password_clnsecurity="mypassword"
 username_clnsecurity="myusername"
 type_clnsecurity="basic"
></PropertySet>

The path and query parameters in this example contain the user-encoded / (slash), this is displayed as: %2F

childlinks_clnquery="ADD2021%2F12"
 account_undkey_clnpath="ADD2021%2F12"

In this example, the disableURLEncoding parameter is set to true. This disables the default URL encoding and avoids double encoding of already encoded characters. This XML example hits the target URL, however the URL is not encoded by the REST Outbound framework. Instead, all elements of the URL are passed unchanged:

http://ServerName:port/siebel/v1.0/data/Account/Account/ADD2021%2F12/?childlinks=ADD2021%2F12