ePostRx System Architecture Presented by AdvanceNet Health Solutions, Inc.

1. ePostRx System Architecture Presented by AdvanceNet Health Solutions, Inc. John Strecker – founder, architect and President July, 2006

2. Agenda • Technology advantage • Source tree • Binary Packaging • XML Configuration Maps • DBView Beans • FormBean Persistence • Data Access Layer • MVC Framework (Console) • B2B Framework (B2B) • Workflow Framework • SOAP (Web Services) • Conclusion

3. The ePostRx Technology Advantage • Developed using the latest web and enterprise technologies that allow open integration and avoid vendor lock: • Transaction/Workflow Engine • J2EE, EJB and XSL and XML • Thin Client User Interface (Web Browser) • JSP, JSTL, Javascript, Servlets, MVC architecture • Software Development kit • Java, XML, Thinlet, JNI, Crypto (Bouncy Castle) • Relational Database Management System • Currently supports MS-SQL 2000+. Support for Oracle and open-source projects MySql and PostgreSql forthcoming.

4. ePostRx Tiered Architecturedrives consistency across enterprise

5. ePostRx Source tree • Project team utilizes IntelliJ as primary development tool. • Software package layout: • com - common helper classes, startup servlets and JSP taglibs • dtds - EJB dtds • lib - contains all external jars that support ePostRx. • projects - • ansHealthB2B** - contains all the business logic • ansHealthConsole** - contains all the Console UI logic. • ansHealthLib - common web shared files • ansHealthUtil - common Utility helper files • ansHealthToolkit** - contains all the toolkit files • ansHealthReports - files that process web Reports • ansHealthRDBMS - contains the schema, generated Java Views,buildload scripts, XML SQL maps etc.. ** build-able project

6. Building ePostRx • ePostRx uses Jakarta ANT1.6+ to build the source files. Run ANT targets in build.bat files in each directory listed below to build the appropriate deployable components: • AnsHealthB2B/build  - builds the JBoss EAR file • ansHealthConsole/build - Builds the Console Web WAR file • ansHealthToolkit/build - builds the toolkit.zip file

7. Deploying ePostRx • Once built, epostrx is deployed as: • EAR file (B2B Transaction Server) • WAR file (contains precompiled or non precompiled JSPs) • Toolkit (Zip file install. **Only if you need to send NCPDP scripts to the server)

8. Deploying ePostRx(cont’d) • EAR and WAR files can be co-located on same application server. • EAR and WAR files can be decoupled on separate servers and communicate via JNDI. • Building separate EAR and WAR files offers flexibility for network topology

9. XML Configuration Maps There are many XML configuration files that support a single user transaction: • Transaction XML Map contains all the Transaction definitions and their associated Reason For Calls (RFC). In addition, all HELP context files are defined for each transaction, as well as the JSP form bean used for presentation persistence. • Note: Any TXN can have multiple RFCs • SQL XML Map contains all the SQL mappings for each Transaction. The SQL is dynamically loaded by the JDBC classes and mapped to JDBC Prepared Statements to process a JDBC call. • Context XML Map contains default user group screen context used for permission processing.

10. XML Configuration Maps (Con’t) • ButtonMappings XML Map contains button definitions that are defined in the Transaction XML Map attributes. Provides a standardized way to centralize all button definitions and their functionality. • Txn, Context and Button maps are located under ANSHealth Console project • SQL maps are located under ANSHealthRDBMS project. • All Maps are loaded and parsed at system startup and persisted in memory

11. XML Configuration MapsTransaction Map Example • <txn-rfc> • <txn-rfc-name>NEW</txn-rfc-name> • <parameter key="request" • pid="console.server.handlers.account.AccountGeneralHandler" • ptype="JCLASS"/> • <parameter key="response" • pid="/htmljsp/account/account_general.jsp" • ptype="JSPPAGE" • template="yes" • buttongroup="NEW"/> • <parameter key="error" • buttongroup="NEW" • ptype="JSPPAGE" • template="yes" • pid="/htmljsp/account/account_general.jsp"/> • </txn-rfc> • <txn-rfc> • PTYPE attribute defines the resource type as JSP, EJB, JAVA, SERVLET,JSPTEMPLATE, HTML etc. • BUTTONGROUP attribute defines the RESPONSE or ERROR buttons to be displayed to the user. These attributes are defined in the ButtonMappings.xml file to standardized button functionality. • TEMPLATE attribute defines whether the response is a template HTML or JSP page (with JSP includes) or a single JSP or HTML page. Transactions with a TEMPLATE attribute of ‘yes’ requires the ProcessHandler to load the response JSP page into the template to be included at run-time.

12. XML Configuration MapsSQL Map Example • <sql-map> • <sql-txn-name>UPDATE_DOCTOR_IDENTIFIERS</sql-txn-name> • <sql-stmt>UPDATE DOCTOR_IDENTIFIERS SET • doctor_id_type_code=?,trading_partner_num=?,doctor_identifier=?,state_num=? WHERE • doctor_identifier_num=?</sql-stmt> • <sql-attributes> • <sql-column-attribute column-name="doctor_id_type_code" column-type="AN"/> • <sql-column-attribute column-name="trading_partner_num" column-type="N"/> • <sql-column-attribute column-name="doctor_identifier" column-type="AN"/> • <sql-column-attribute column-name="state_num" column-type="N"/> • <sql-where-attribute column-name="doctor_identifier_num" column-type="N"/> • </sql-attributes>

13. XML Configuration Maps (Con’t)Context(Permissions) Map Example • <context> • <usergroup name="EPOSTRXDEMOUSER" displayname="Demo User"> • <categorygroup name="MAIN_MENU_GROUP" displayname="Main Menu" permission="READWRITE"> • <category name="MYEPOSTRX" displayname="myEpostRx"> • <subcategory> • <name>WELCOME</name> • <displayname>Welcome</displayname> • <permission>READWRITE</permission> • <defaultrfc>READ</defaultrfc> • <type>TAB</type> • </subcategory> • <subcategory> • <name>QUICKSEARCH</name> • <displayname>QuickSearch</displayname> • <permission>READWRITE</permission> • <defaultrfc>NONE</defaultrfc> • <type>SYSTEM</type> • </catagorygroup> • </usergroup> • </context>

14. XML Configuration Maps(Con’t)Button Map Example • <button-map> • <button-group>LIST</button-group> • <button-group-attributes display-required-fields="no"> • <parameter name="NEW" event="onclick" function="processNew()" readonly="yes" shortcutname="NEW(Ctrl+Z)" • shortcutcode="90"/> • <parameter name="REFRESH" event="onclick" function="processListOK()" readonly="yes" • shortcutname="REFRESH(Ctrl+J)" shortcutcode="74"/> • </button-group-attributes> • </button-map> • <button-map>

15. DBView Bean • To provide uniformity and ease of SQL access for all resources that require specific presentation or database table data, an abstract interface class– DBViewBean was created. • The DBViewBean provides many common SQL methods necessary to access the underlining ePostRx JDBC classes. • A presentation view object is then created which maps uniquely to a SQL query. For example: • AccountAddressView extends DBViewBean. • TXNID = ACCOUNT_ADDRESS • RFC may be READ, INSERT, NEW, UPDATE, LIST or DELETE • SQL map contains query for each RFC and TXNID (i.e. READ_ACCOUNT_ADDRESS) • TXN Map contains entry called ACCOUNT_ADDRESS with RFC of READ

16. DBViewBean (Con’t) • Approach allows maximum encapsulation of specific database table or JSP presentation view. These objects then can be re-used in other processing to query persisted data. • Each DBViewBean is mapped to a SQL TXNID ID defined in the SQL Maps. • Contained in com.generic.jdbc package

17. DBViewBean (Con’t) • Code Example: List all account address for given account AccountAddressViewBean avb = new AccountAddressViewBean(); avb.setWhereKey(“account_num”, account_num); avb.ListView(); if(avb.isResultSet()){ // iterate through resultset collection for (int i=0; i< avb.getResultSetRowCount(); i++){ avb.setRow(i); System.out.println(“Dump record” + avb.getRow(i)); } }

18. FormBean Persistence • Similar to Struts, the ePostRx Framework has implemented the FormBean persistence model. • All JSP presentation attributes are defined as Java Bean accessors (Setters/Getters) within a unique java class. • Each class supports a unique JSP or View. • Bean attributes are updated using the Java Reflection API upon a URL POST. • If an error occurs in a Request Handler, the data on the screen is captured and redisplayed to the user. • Located in ANSHealthConsole project/servers

19. Data Access Layer • Contained in com.generic.jdbc package • Responsible for the JDBC SQL execution of DBViewBean(s). • Manages DB Connection pooling for each SQL request. • Specifics: • Retrieves the associated SQL Map from memory using the DBViewBean’s TXNID. • All SQL statements use JDBC Prepare Statements. SQL maps contain all column and where attributes for each Txn query. • Maps user entered input to column and where attributes prior to SQL execution. • Executes both single and batched SQL transaction(s). • Builds Resultset of epostrx EntityObjects to return to caller for post-processing.

20. Data Access Layer (Con’t) • EntityObject is the primary SQL resultset data container. Each EntityObject represents a SQL resultset row. • For a given row, EntityObject contains HashMap which contains result set columns. • Various support methods to manipulate data. • SQL READS return Collection of EntityObjects. • SQL INSERT or UPDATEs pass collection of EntityObjects to insert/update.

21. Data Access Layer (Con’t) • Code Example. AccountAddressViewBean avb = new AccountAddressViewBean(); avb.setWhereKey(“account_num”, account_num); avb.ListView(); if(avb.isResultSet()){ // iterate through resultset collection for (int i=0; i< avb.getResultSetRowCount(); i++){ EntityObject row = avb.getRow(i); System.out.println(“Account Address1 + row.getString(“account_address1”)); System.out.println(“Account Address2 + row.getString(“account_address2”)); System.out.println(“Dump entire record” + row.toString()); } }

22. MVC Framework The Model 2 architecture, shown below, is a hybrid approach for serving dynamic content, since it combines the use of both servlets and JSP. It takes advantage of the predominant strengths of both technologies, using JSP to generate the presentation layer and servlets to perform process-intensive tasks.

23. MVC Framework (Con’t) • Upon review of Struts and Java Pet-Store(JPS) technologies, it was determined that although these technologies provided very robust and open-source solutions, they lacked the essence of true transactional processing as detailed below. • Both Struts and JPS do not provide a means of triggering events through transactions. All events are triggered through URL maps. These can become very cumbersome when integrating client side links to buttons, navigation links, permissions etc. • Because there is no centralized transaction model, the ability to govern user actions and selection of screen functions through permissions grows in complexity. Need to wrap each link with a permission check. Ugh! • Because there is no transaction engine, a single transaction cannot be mapped seamlessly to an SQL CRUD event such as UPDATE or INSERT for the user selected transaction. Therefore, you need to add custom and complex code to each request handler to perform your queries.

24. MVC Framework (con’t)Transaction Model • ANSHealth Transaction Model Approach can be linked to SQL XML maps removing need to embed SQL in application code and providing centralized repository for future database schema migrations. • Additionally, SQL queries can be become more dynamic and abstract to the request handler because your providing real-time lookup based upon user transaction. The transaction provides the link to any and all processing required!

25. MVC Framework (Con’t)TxnJobHandler • In keeping with a MVC model 2, the ePostRx Framework handles client POST requests through the single servlet – the TxnJobHandler as follows: • <form method=’POST’ action = ‘/anshealthConsole/ans’> • Embedded in each client URL request are transaction attributes defined as Name/Value pairs such as: • TXN – name of transaction to process request • RFC - reason for call (UPDATE, DELETE, READ, NEW, REPAINT etc.) • Upon receipt of the URL POST request, the TxnJobHandler servlet validates the user request against the Transaction XML maps. If the Transaction exists, the servlet calls the support class ProcessHandler which further processes the request in detail. If the requested transaction is not found, TxnJobHandler returns an error to the caller.

26. MVC Framework (Con’t)ProcessHandler • ProcessHandler controls the transaction job request processing as determined by the Transaction XML maps. It provides the three critical functions: • Session Management – creates user session objects and updates accordingly with pertinent information necessary for client side processing. • Security Management – validates all user requests based on user’s permission profile to ensure they have access to the requested functional area. • Dispatch Management – dispatches the appropriate Java class, HTML, JSP, JSP template, JAR, Servlet or EJB resource to process the user request. ProcessHandler categorizes a single user request into two actions: • PreRequest is used to process the request before the intended response. • PostRequest is used to process the intended response to the client.

27. MVC Framework (con’t)Interprocess Communication • When a process is dispatch by the ProcessHandler, a message interface is implemented by all Request Handlers to standardize message attributes across all requests. • The base Message Object is comprised of a Header object and Body Object, each possessing their own attributes too numerous to mention here. Together, the Header and Body Objects comprise the following run-time messages: • MSGRequest is sent to all request handlers to process the request. • MSGResponse is returned by all request handlers containing process run-time information.

28. MVC Framework (Con’t)RequestHandlers • The Request Handlers are Java classes that are dispatched by the ProcessHandler that process the Validate, Request and Response. Similar to Struts Action classes. • For example, a Request action might be to execute a SQL query required for the response JSP page. Each client request is mapped uniquely to a handler through the Transaction XML map, PID attribute. The PARAMETER attribute defines the REQUEST, RESPONSE and ERROR.

29. MVC Framework (Con’t)Piecing it all together Hybrid framework similar to Struts and PetStore XML maps in memory POST request TxnJobHandler Servlet HTTP JSP returned Txn MapsSql MapsContext Maps ProcessHandler Process Request And Response Interprocess communication Data Access Layer Request Handlers Handlers may call EJB classes for support Database B2B Processing

30. B2B Framework • B2B framework was originally architected to handle asynchronous SCRIPT events from client toolkit. • Evolved over time to package and process business logic that could be “extended” to accommodate additional external requests other than UI. If specific to UI, stayed in UI handler classes! • Uses Session Bean (EJB) architecture. All session beans use Bean Manage Persistence (BMP) to leverage existing helper classes and Data Access Layer. • All beans accessible via Session Bean lookup via JNDI. • ANSHealthConsole (UI) calls beans via lookup class for specific events such as pricing, drug checks, drug lookups etc.. • Processing that is thread oriented are developed as Message Driven Beans (MDB)

31. Workflow Framework • There are many open-source workflow frameworks available such as: • OS Workflow - http://www.opensymphony.com/osworkflow • Open For Business -http://www.ofbiz.org • These solutions were investigated. Although robust and open-source(free), without additional custom changes, these solutions did not provide the granularity to trigger on custom messages like SCRIPT as well as provide static and dynamic routing of messages within the ePostRx framework. Therefore, to provide greater flexibility and embedded application control, the option of developing a home-grown solution was selected.

32. Workflow Framework (Con’t) • Rules are the basic building blocks of the ePostRx Rules Engine. Rules allow users to build criteria for workflow event triggering. Each rule is comprised of two (2) distinct parts: • Action defines what type of action to perform such as validate specific EDI data elements, or call functions. • There are various actions the user can define to trigger events. • Responsedefines the post event to perform after the initial action is successful. • There are various response the user can define to trigger events.

33. Workflow Framework (Con’t) • Each trading partner can have multiple, unique workflow types assigned, with each workflow containing multiple assigned rules. • Event driven model: • Unlike the traditional single-daemon process where users “drop” transactions into a processing bucket and external threads poll for specific events, this model provides greater scalability and management of transactions. • Each thread owns an instance of the Rule-Workflow Object and can control the functionality necessary to process a message or order request until completion.

34. Each trading partner (location) can have multiple, unique workflow types assigned, with each workflow containing multiple assigned rules

35. Example ‘Dispense’ Workflow Rules

36. Workflow Framework (Con’t) Item B to be Scrubbed by Workflow YY • Workflow Engine Rule1 Rule2 Rule3…. Item A to be Scrubbed by Workflow XX Rule1 Rule2 Rule3…. WorkflowManager, RulesManager and ActionManager classes comprise workflow processing Each item to be processed is bound to a Rule Workflow Object. All rule actions/responses are executed against the item. Depending upon each rule configuration, processing is TOP DOWN and may continue or stop if and error occurs. Rule Execution State is maintained in the database.

37. Workflow Framework (Con’t) • Specific transactions can be synchronous which the user waits for a response. Other transactions will be asynchronous and continue background processing independent of the user’s initial request. • Asynchronous requests will be handled by Message Driven Beans (MDB) within the Application Server (AS) Container.

38. Workflow Framework (Con’t) • All workflow state is persisted in database tables. • All Rule Engine transactions are applied to an item of processing (i.e. Order line, SCRIPT message).. • Once a Rule Action is found to be TRUE, the corresponding Rule Response is invoked and the engine is released for the associated execution thread. • Rule business logic contained in java objects. Common interface to access rule objects from framework via ClassForName call.

39. SOAP (Web Services) • Contained in the B2B processing are various SOAP(Web Service) processor calls. • Epostrx uses XFIRE for SOAP services which is built on a an XML messaging layer made up of Transports which provide Channels for communication. • HTTP Transport A standard SOAP over HTTP transport. JMS Transport Ultra reliable, fast, asynchronous messaging via JMS. XMPP/Jabber Transport XMPP is an asynchronous messaging protocol which can be used for SOAP.

40. Conclusion • Download the epostrx source code and start to explore and learn. • Having a good IDE such as Intellj makes all the difference in exploring! • Get on the ePostRx forum and ask questions (www.anshealth.com).