Bookshelf v7.8: Execute Method

Integration Platform Technologies: Siebel Enterprise Application Integration > EAI Siebel Adapter > EAI Siebel Adapter Methods >

Execute Method

The Execute method can be specified on the EAI Siebel Adapter to perform combinations of various operations on components in an integration object instance. This method uses the following operations:

query
querypage (same as query when used as children operation)
sync (the same method as Synchronize and is the default operation)
upsert
update
updatesync
insert
insertsync
delete
skipnode
skiptree
none

NOTE: A none operation is equivalent to operation sync.

These operations perform the same tasks as the related methods. For example, the delete operation makes the EAI Siebel Adapter delete the business component record matched to the particular integration component instance. However, what will be done to the children depends on the combination of the parent operation and the child operation. For information, see Table 14.

NOTE: The operation method names are case sensitive. If you misspell an operation method, the EAI Siebel Adapter assumes the default operation.

An XML document sent to a Siebel application can include operations that describe whether a particular data element needs to be inserted, updated, deleted, synchronized, and so on. These operations can be specified as an attribute at the component level. They cannot be specified for any other element.

The following XML example demonstrates using the upsert and delete operation to delete a particular child record without updating the parent:

<Account operation="upsert">

<Name>A. K. Parker Distribution</Name>

<Location>HQ-Distribution</Location>

<Organization>North American Organization</ Organization>

<Description>This is the key account in the AK Parker
Family</Description>

<HomePage>www.parker.com</HomePage>

<LineofBusiness>Manufacturing</LineofBusiness>

<Contact operation="delete">

<JobTitle>Senior Mgr of MIS</JobTitle>

<LastName>Graner</LastName>

<Account>A. K. Parker Distribution</Account>

<AccountLocation>HQ-Distribution</AccountLocation>

</Contact>

</ListOfContact>

</Account>

</ListofSampleAccount>

</SiebelMessage>

About Execute Method Operations

Specify an attribute named operation, in lowercase, to the component's XML element. The legal values for this attribute are upsert, sync, delete, query, update, insert, updatesync, insertsync, skipnode, skiptree, and none. If the operation is not specified on the root component, the sync operation is used as the default.

NOTE: Specifying an operation within the <ListOf> tag is not supported. For information on the <ListOf> tag, see XML Reference: Siebel Enterprise Application Integration.

Each child node inherits the operation from the parent if another operation is not explicitly specified. If another operation is explicitly specified, then Table 14 represents the results of the operation on the current node.

Table 14. Operation Outcomes for the Child Node
Operation	What happens to the current node	What happens to unmatched children of current node
upsert	Update or insert	Leave alone
sync	Update or insert	Delete
update	Update	Delete
updatesync	Update	Delete
insert	Insert	Leave alone
insertsync	Insert	Delete
skipnode	Skip this node	Leave alone
skiptree	Skip the tree	Not applicable

Example of a Parent Node Using a Sync Operation

This example demonstrates the effects of records after a sync operation is performed. Table 15 is a high level representation of a parent node using the sync operation of the Execute method.

Table 15. Representation of a Parent Node Using the Sync Operation
Record In Database	Integration Object Instance	Record After Execute Operation
Account1 Contact0 Contact1	Account1 `operation=sync` Contact1 Contact2	Account1 Contact1 Contact2

Record in Database

The code represents GENCOMM0 and GENCOMM1 being retrieved as the contacts for this example.

<?xml version = "1.0" encoding = "UTF-8"?><?Siebel-Property-Set EscapeNames="false"?>

<AccountStatus>Active</AccountStatus>

LanguageCode>ENU</LanguageCode>

<Location>San Francisco, CA</Location>

<Name>GenComm</Name>

<FirstName>GENCOMM0</FirstName>

<LastName>GENCOMM0</LastName>

<Organization>Default Organization</Organization>

</Contact>

<FirstName>GENCOMM1</FirstName>

<LastName>GENCOMM1</LastName>

<Organization>Default Organization</Organization>

</Contact>

</ListOfContact>

/Account>

</ListOfAccount>

</SiebelMessage>

Integration Object Instance

The following code represents the sync operation acting on the contacts from the database.

<?xml version = "1.0" encoding = "UTF-8"?>

<?Siebel-Property-Set EscapeNames="false"?>

<Account operation="sync">

<AccountStatus>Inactive</AccountStatus>

<Location>San Francisco, CA</Location>

<Name>GenComm</Name>

<FirstName>GENCOMM1</FirstName>

<LastName>GENCOMM1</LastName>

<Organization>Default Organization</Organization>

</Contact>

<FirstName>GENCOMM2</FirstName>

<LastName>GENCOMM2</LastName>

<Organization>Default Organization</Organization>

</Contact>

</ListOfContact>

</Account>

</ListOfAccount>

</SiebelMessage>

Result Record in Database

The following code represents the results of the sync operation after acting on the two contacts from the database.

<?xml version = "1.0" encoding = "UTF-8"?>

<?Siebel-Property-Set EscapeNames="false"?>

<AccountStatus>Inactive</AccountStatus>

<Location>San Francisco, CA</Location>

<Name>GenComm</Name>

<FirstName>GENCOMM1</FirstName>

<LastName>GENCOMM1</LastName>

<Organization>Default Organization</Organization>

</Contact>

<FirstName>GENCOMM2</FirstName>

<LastName>GENCOMM2</LastName>

<Organization>Default Organization</Organization>

</Contact>

</ListOfContact>

</Account>

</ListOfAccount>

</SiebelMessage>

In this case, if a matching Account1 exists in the database, then the EAI Siebel Adapter will perform an update of that record. If no record matching Account1 exists, then the EAI Siebel Adapter will insert a new account.

For all the matching child contacts, the sync operation is inherited. Therefore, if the child exists, it will be updated. If the child does not exist, it is inserted. Any child contacts that exist in the database but do not match the integration object instance (unmatched children) are deleted.

The reason for this logic is that the sync operation makes the record in the database look like the integration object instance.

Example of a Parent Node Using an Update Operation

This example demonstrates the effects of records after an update operation is performed. Table 16 is a high level representation of a parent node using the update operation of the Execute method.

NOTE: The examples represented by Table 16, Table 17, and Table 20 basically have the same result. However, as reflected in Table 19, the children do not automatically inherit Update if it is only set for the root.

Table 16. Representation of a Parent Node Using the Update Method
Record In Database	Integration Object Instance	Record After Execute Operation
Account1 Contact0 Contact1	Account1 `operation=update` Contact1 Contact2	Account1 Contact1 Contact2

In this case, if a record matching Account1 exists in the database, then the EAI Siebel Adapter updates that specific record. If no matching account exists, then the result of the EAI Siebel Adapter is an error with this message:

Insert operation on integration component 'Account' failed because a matching record in business component 'Account' with search specification '[Name] = "GenComm" AND [Location] = "San Francisco, CA"' was found (SBL-EAI-04383)

For all the matching child contacts, the update operation is inherited. Therefore, if the child exists, it will be updated. If the child does not exist, it is inserted. For child contacts that exist in the database but do not match the integration object instance, they will be deleted. These may be child contacts created or associated with the Account by default.

This is very similar to the previous example except the record must exist in the database.

Example of a Parent Using an Update Operation and One More Child Using an Insert Operation

This example demonstrates the effects on records after an update operation acts on the parent, and an insert operation acts on one of the children records. Table 17 is a high level representation of this example.

Table 17. Representation of Two Operations
Record In Database	Integration Object Instance	Record After Execute Operation
Account1 Contact0 Contact1	Account1 `operation=update` Contact1 Contact2 `operation=insert`	Account1 Contact1 Contact2

In this case, if a record matching Account1 exists in the database, then the EAI Siebel Adapter updates that record. If no record matching Account1 exists, then the result from the EAI Siebel Adapter is an error.

You can also override the parent operation as in the case for Contact2. Since Contact2 does not exist, and there is an explicit insert operation, it will be inserted. Any unmatched children will be deleted as part of the parent operation (update). This is the reason why Contact0 is deleted.

If you are explicitly overriding the parent operation, you must make sure the operation applies. For example, the two combinations in Table 18 and Table 19 will fail. In Table 18, it fails because an insert is attempted when Contact1 already exists in the database.

Table 18. Representation of Overriding a Parent Operation Using Insert
Record In Database	Integration Object Instance	Record After Execute Operation
Account1 Contact0 Contact1	Account1 `operation=update` Contact1 `operation=insert` Contact2 `operation=insert`

In Table 19, the update fails since SubContact3 inherits from Contact2's operation, and Subcontact3 does not exist in the database.

Table 19. Representation of Overriding a Parent Operation Using Update
Record In Database	Integration Object Instance	Record After Execute Operation
Account1 Contact1 Contact2 SubContact1 SubContact2	Account1 Contact1 Contact2 `operation=update` SubContact1 SubContact3

Example of a Parent Using the Update Operation and One More Child Using the Upsert Operation

This example demonstrates the effects of records after an update operation acts on the parent, and an upsert operation acts on one of the children records. Table 20 is a high level representation of this example.

Table 20. Representation of Overriding a Parent Operation Using Upsert
Record In Database	Integration Object Instance	Record After Execute Operation
Account1 Contact0 Contact1	Account1 `operation=update` Contact1 Contact2 `operation=upsert`	Account1 Contact1 Contact2

In this case, if a record matching Account1 exists in the database, then the EAI Siebel Adapter updates that record. If no record matching Account1 exists, then the result of the EAI Siebel Adapter is an error.

For a record matching Contact2, the upsert operation overrides the update operation. Therefore, if Contact2 exists, it is updated. If no record matching Contact2 is found, it is inserted. Unmatched child contacts are deleted.

Example of a Parent Using the Upsert Operation and One More Child Using the Sync Operation

This example demonstrates the effects of records after an update operation acts on the parent, and a sync operation acts on one of the children records. Table 21 is a high level representation of this example.

Table 21. Representation of Overriding a Parent Operation Using Sync
Record In Database	Integration Object Instance	Record After Execute Operation
Account1 Contact0 Organization2 Contact1 Organization2 Contact2 Organization2	Account1 `operation=upsert` Contact1 Organization1 Contact2 `operation=sync` Organization3	Account1 Contact0 Organization2 Contact1 Organization1 Organization2 Contact2 Organization3

In this case, if a record matching Account1 exists in the database, then the EAI Siebel Adapter updates that record. If no record matching Account1 exists, then the EAI Siebel Adapter inserts the record.

For all child contacts, the upsert operation applies. Therefore, if the child exists, it is updated. If the child does not exist, it is inserted. For child contacts that exist in the database, but do not match the integration object instance, they will remain unchanged because upsert does not delete children.

In the case of Contact2, which has the sync operation overriding the upsert operation, it is updated, and its children are synchronized.

Skiptree Operation

The whole sub tree rooted at this node is not processed. It is the same as that whole sub tree not existing in the integration object instance. Operations specified in child nodes do not affect processing in any way since the EAI Siebel Adapter does not act on the child.

<?xml version="1.0" encoding="UTF-8"?>

<?Siebel-Property-Set EscapeNames="false"?>

<Account operation="upsert">

<Location>cold storage</Location>

<Contact operation="skiptree">

<FirstName>firstname</FirstName>

<LastName>contact1</LastName>

<Organization>Default Organization</Organization>

<BusinessAddress operation="insert">

<City>San Mateo</City>

<AddressName>primary address</AddressName>

</BusinessAddress>

</ListOfBusinessAddress>

</Contact>

<FirstName>firstname</FirstName>

<LastName>contact2</LastName>

<Organization>Default Organization</Organization>

</Contact>

</ListOfContact>

</Account>

</ListOfSampleAccount>

</SiebelMessage>

Based on this example, the account is upserted. The processing of the first contact is completely skipped although the business address child has an insert operation set. Also, the second contact is upserted.

If the skiptree operation is specified for the account integration component, then the EAI Siebel Adapter skips processing the complete account. This results in no operation. It is possible to have many accounts with some having skiptree specified as shown in the following example. The EAI Siebel Adapter processes the trees that do not have skiptree specified.

<?xml version="1.0" encoding="UTF-8"?>

<?Siebel-Property-Set EscapeNames="false"?>

<Account operation="skiptree">

<Location>cold storage<Location/>

</Account>

<Account operation="upsert">

<Location>cold storage<Location/>

</Account>

</ListOfSampleAccount>

</SiebelMessage>

Skipnode Operation

Similar to all other Execute operations, the children nodes inherit the semantics of the operation from the parent nodes. If a node has operation skipnode set, then the EAI Siebel Adapter will skip setting field values for all children unless a child has an explicit operation set that will override.

<?xml version="1.0" encoding="UTF-8"?>

<?Siebel-Property-Set EscapeNames="false"?>

<Account operation="skipnode">

<Location>cold storage</Location>

<FirstName>firstname</FirstName>

<LastName>contact1</LastName>

<ListOfContact_Organization>

<Contact_Organization>

<Organization operation="insert">MyOrganization</Organization>

</Contact_Organization>

</ListOfContact_Organization>

</Contact>

<Contact operation="upsert">

<FirstName>firstname</FirstName>

<LastName>contact2</LastName>

</Contact>

</ListOfContact>

</Account>

</ListOfAccount>

</SiebelMessage>

Based on this example, the account is skipped. However, the EAI Siebel Adapter will attempt to insert the two contacts.

Integration Platform Technologies: Siebel Enterprise Application Integration		Copyright © 2008, Oracle and/or its affiliates. All rights reserved. Legal Notices.