The application must track specific user actions / events and communicate them to Responsys through a SOAP service.

Transcription

1 Responsys Integration Architecture Scope The intention of this section is to present the high level architecture of the integration between the Forever21 websphere commerce application and the external SOAP service called Responsys. Requirements The application must track specific user actions / events and communicate them to Responsys through a SOAP service. Proposed architecture Taken into account scalability, decoupling of components and the maintainability of the application, we recommend the creation of an internal Queue to store the user events and a component in charge of dispatch the events into the Queue (dispatcher). Using this approach any component of the application (EJB, Task, etc) could access to the dispatcher (getting it from the context) and dispatch an event, without making any consideration on which are the receivers/consumers components and the details of the implementation will be in one place of the code (the dispatcher). In future releases, we could have newer types of events and all components of the application could listen to them and decide if they are interested or not, executing the corresponding actions. The last component of the architecture will be the ResponsysPlugin, it will consume the events from the Queue and it will send the relevant information to the Responsys service.

2 This architecture is based on the assumption that we will have a one way async communication with the responsys api, just to track event or trigger async behaviour based on the user behaviour on the site. If there are actions that could be triggered and could be generating an immediate action triggered by responsys (i.e. forward the user to an specific page, or show a pop up). We need to revise this architecture to consider this scenario. Components UserEvent: it represents a user event (hierarchical tree of classes to represent the relevant user events, example: OrderConfirmationEvent) Dispatcher (EJB component): allow to dispatch user events into the Queue Queue: maintain all the user events and deliver them to the interested components of the application, ensures the events will not be lost. ResponsysPlugin (EJB component): listen to the user events and send the relevant information to the Responsys service.

3 Implementation details Scope This section covers the details of the implementation of the main components. Bus / JMS Queue Bus configured in the Websphere server using as destination a JMS queue allowing the message based architecture. All the events (JMS messages containing serialized objects) are sent to this bus, it will deliver the events to the corresponding consumers and it ensures the events are not lost if the server goes offline (persistent messages). ServiceLocator It s a singleton component used to locate components in the Websphere container, it encapsulates the JNDI code and also maintains the components cached avoiding the repeated JNDI lookups. Example code: // Obtains the EventsDispatcher component from the Websphere container EventsDispatcher eventdispatcher = ServiceLocator.getInstance().getEventDispatcher(); Project F21EventDispatcher EJB project that exposes a stateless Enterprise Bean called EventsDispatcher in charge of dispatch the events into the JMS queue. The events are represented as a hierarchical tree of serializable classes that could be instantiated and sent into JMS messages. The EventDispatcher could be obtained using the ServiceLocator and called from any point of the code as controller commands, task, etc.

4 Example code: // Obtains the EventsDispatcher component from the Websphere container EventsDispatcher eventdispatcher = ServiceLocator.getInstance().getEventDispatcher(); // Creates and dispatches a user event UserEvent userevent = UserEvent.create(" ", "wtrentin@velocitypartners.net"); eventdispatcher.dispatchevent(userevent ); Project structure: Project F21ResponsysPlugin Basically this EJB project receives the user events and executes the corresponding calls to the Responsys service.

5 The project contains the following classes: EventsReceiverMDB: Message Driven Bean that receives the events (JMS messages) from the bus. EventsProcessor: processes the events with the help of a class implementing the visitor pattern (ResponsysEventVisitor) to avoid the extensive use of the sentence instanceof in the code to detect the type of event to be processed. ResponsysEventVisitor: executes the corresponding action for each event. ResponsysService: executes the calls to Responsys using the generated stubs by the wsdl2java tool. Flow of execution: EventsReceiverMDB EventsProcessor ResponsysEventVisitor ResponsysService Project structure: