TDG Rafael Z.Frantz Committed to research! TDG Site Manager 1.1

example-1-2-0-Ex2 (SGL)

     Below we show an example of EAI solution designed using Guaraná DSL. To set the scene, we will use the scenario of an application integration problem under study at Unijuí, Brazil. Apart from some small modification introduced to highlight the issues of our research interest, the scenario is realistic.

     Unijuí has five applications involved in a hand-crafted process whose goal is to invoice their employees of the private phone calls they make using the University's phones.  Each application runs on a different platform and was designed without integration concerns in mind. There is a Call Center System (CCS) that records every call every employee makes from one of the telephones this university provides to them.  Every month, an analysis is performed to find out what calls have a cost and are not related to the work activities of the employees; such calls are debited to the employees by using a Debit System (DS).  There is also a Human Resources System (HRS) that provides personal information about the employees, including their names, phone numbers, social security numbers, and so forth.  There are two additional systems to send mail or SMS messages.  The goal of the integration solution is to automate the invoicing of the calls that an employee makes and are not related to his or her work activities.

     Figure~\ref{fig:unijui-integration-solution} depicts our integration solution. The applications are connected to an integration solution through wrappers (1). A wrapper contains tasks to interact with the application's interface layer (database, gateway, user interface, and so on), send and/or receive messages from the integration solution. The decorator (21) simply indicates which application and interfacing layer are being integrated/accessed.

     The integration flow for the solution presented in this example begins in the wrapper of application CCS with a timer task (2). This task creates an activation message every two minutes and sends it, through a slot to the next task, which is a file interfacing task (3). This task is responsible for accessing the files where the application CCS writes the phone calls, creates a message for each call and sends them to the next slot one-by-one. The exit port of this wrapper reads each message from this slot and then sends it to the integration link (4), making it available for the entry port of the central process block (5). This process contains a composite task that starts with a filtering task (6). This task filters out messages that do not have a cost for the university, and allow just toll calls to remain in the flow. Those messages are written to the next slot, and will be read by the next task, a replicator (7). The replicator makes copies of the original message. In this case one copy is sent to the wrapper of the application Human Resource System (HRS) and the other to the next element in the current process. In this integration solution we need to append missing information about the employee to the message, like: name, department, e-mail and mobile phone. This information is in the HRS, that is why it is also integrating our solution. The message copy received by the wrapper of HRS, through the ports (8), will be processed by a custom task (9). This task produces an outbound message that represents a database query to be executed by the database data source (10). After that the content enricher (11) receives the result from the HRS's wrapper and enriches the original message with it. Now the enriched message is sent to the next slot, the one that connects with the exit port (12). This port is also connected to three integration links that allow sending a message copy to DS, SMS and MS.

     The first integration flow after the exit port (12) connects the process (5) to the wrapper of the DS application. This wrapper receives the message through its entry port and makes it available for the first internal task of the wrapper, the translator task (13). The translator is responsible for translating the current message format into a new format that the DS can understand, and then immediately writes the message into the slot between the translator and the database data source (14). This task accesses the database of the DS and stores the message.

     The second flow connects the same exit port (12) to the other process (15) which have a unique internal task, a slimmer task. A slimmer is responsible for removing some information from the message in order to make it smaller before sending it to the SMS. The SMS is an external application that allows sending messages to mobile phones. In its wrapper, there is a translator (16) that receives the inbound message and translates it into a special format that the SMS can understand. Once the SMS offers a public gateway the interaction can be done by a RPC access (17), that forwards the inbound message.

     The last copy of the message goes to the flow (18) that now connects the process (5) with the wrapper of the MS. This wrapper integrates the application allowing the solution to send e-mails with all the details about the employee's call. As in the other wrappers it is important to translate the inbound message into a message format that the MS can understand. This is done using a translator (19) inside the wrapper, just after the entry port. The translated message now goes, through a slot,  to the next task, the RPC access (20), and then to the MS.