Introduction

One of the most commom needs when integrating Siebel with other applications is knowing when to push information from Siebel to the other platforms. There are wide variety of solutions and architectures. Here we share a highly reliable asynchronous solution with Queues.

Architecture

In our proposed architecture we rely on a database table, either internal or external to the Siebel schema, depending on the type of project, that stores the id of the changed record, the type of record, as well as the processing state (to process, processed, other states can be used if needed), as well as what type of change was made (update, delete, insert, other). Other information can also be stored if needed.

Inserts and Updates, for most cases, are straightforward. A workflow policy can be used to check the relevant tables using a personalized workflow policy component. This will enable the fields relevant to the external applications to be monitored. A workflow can then be created to obtain the Row Id or any other relevant fields from the Business components and write them to the queue.

Nevertheless, there are some special cases. The trigger is obtaining the Id of the record that is being updated. However, in some cases you might want to get information from BC’s that are over extension tables or from BC’s that are not the main Business component of any Business Object. In the first scenario, If the Id is the same as that of the Main table, there are no issues. However, if the Id is different, then the Workflow policy component needs to be configured to pass the correct id for each table. In the remaining case, it depends on the situation, but usually the best solution is to create a new Business Object, where you can use the Business component you need as the main one.

To register deleted records the process is a little different, as you will not be able to capture the deleted Id’s with a trigger.

There are however two options: A run-time event or Coding directly on the business component. The first approach works correctly for cases where the delete is not made on an extension table. Nevertheless, since the delete on an MVG applet will be sent through this process, an error will be thrown if a run-time event is present and the error is not disabled. This process can also cause issues if a rollback occurs during the creation of a record, regardless of the creation happening in the UI or in a background process.

In opposition direct coding enables us to bypass this issue by programming specifically for each process.

Conclusion

With the above, Siebel will display information on relevant updates for external applications/processes. Using columns tailored for each project, this will enable these applications to get only the necessary updated data, when it is updated. 

#Siebel #Queue #Workflow #RunTime