Jump to: navigation, search

Difference between revisions of "Stardust/Knowledge Base/Integration/Camel/Email Trigger with Process Attachments"

Line 9: Line 9:
 
== Process Model  ==
 
== Process Model  ==
  
[[Image:Stardust Integration Camel EmailTrigger Model1.png|900x400px]]
+
[[Image:Stardust Integration Camel EmailTrigger Model1.png|900x400px]]  
 +
 
 +
 
 +
 
 +
The model above contains two processes viz. Purchase and Redemption. For simplicity, both the processes have been designed to be identical. We define two simple primitives viz. "Client" and "MailBody", both of type String. The "Client" data will be populated based on the value of a lookup made from within the Camel route depending on certain process data, while "MailBody" will contain the text of the Email. The first activity named "Wait for Doc Sync" is a Route activity which is set to Hibernate initially. We will discuss the reasons for this decision later in the article. The subsequent activity displays the contents of the data above in the Stardust portal. Note that both the processes need to be able to support "Process Attachments". This can be enabled by changing the process properties.

Revision as of 01:40, 4 September 2012

 Introduction

This article discusses an integration scenario where a Stardust process is kicked off by an incoming mail in a POP3 account that is being monitored by Camel. The incoming mail is parsed for certain keywords and the process to be invoked is selected dynamically based on the value of the keyword. Certain process data is also selected dynamically by parsing the mail contents. Any attachments that are part of the mail are converted into Documents and associated with the newly created Process Instance.

All the artifacts discussed in this article can be downloaded from here.


Process Model

Stardust Integration Camel EmailTrigger Model1.png


The model above contains two processes viz. Purchase and Redemption. For simplicity, both the processes have been designed to be identical. We define two simple primitives viz. "Client" and "MailBody", both of type String. The "Client" data will be populated based on the value of a lookup made from within the Camel route depending on certain process data, while "MailBody" will contain the text of the Email. The first activity named "Wait for Doc Sync" is a Route activity which is set to Hibernate initially. We will discuss the reasons for this decision later in the article. The subsequent activity displays the contents of the data above in the Stardust portal. Note that both the processes need to be able to support "Process Attachments". This can be enabled by changing the process properties.