Product Overview - PowerPoint

Document Sample
Product Overview - PowerPoint Powered By Docstoc
					ePostRx System Architecture

Presented by AdvanceNet Health Solutions, Inc.
John Strecker – founder, architect and President

July, 2006
        Today‟s 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
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.
     ePostRx Tiered Architecture
drives consistency across enterprise
           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
          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 file
        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)
 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
Building separate EAR and WAR files
offers flexibility for network topology
        XML Configuration Maps
There are many XML configuration files that support a single user

   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.
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
 Txn, Context and Button maps are located under
 ANSHealth Console project
 SQL maps are located under ANSHealthRDBMS
 All Maps are loaded and parsed at system
 startup and persisted in memory
            XML Configuration Maps
                   Transaction Map Example
                      <parameter key="request"
                      <parameter key="response"
                       <parameter key="error"

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.
         XML Configuration Maps
                        SQL Map Example

       <sql-column-attribute column-name="doctor_id_type_code" column-
       <sql-column-attribute column-name="trading_partner_num" column-
       <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-

XML Configuration Maps (Con‟t)
    Context(Permissions) Map Example
  <usergroup name="EPOSTRXDEMOUSER" displayname="Demo User">
     <categorygroup name="MAIN_MENU_GROUP" displayname="Main Menu"
       <category name="MYEPOSTRX" displayname="myEpostRx">
 XML Configuration Maps(Con‟t)
                Button Map Example
     <button-group-attributes display-required-fields="no">
        <parameter name="NEW" event="onclick"
function="processNew()" readonly="yes"
        <parameter name="REFRESH" event="onclick"
function="processListOK()" readonly="yes"
                 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.
 – SQL map contains query for each RFC and TXNID (i.e.
 – TXN Map contains entry called ACCOUNT_ADDRESS with RFC of
      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
        DBViewBean (Con‟t)
Code Example: List all account address
for given account
   AccountAddressViewBean avb = new AccountAddressViewBean();
   avb.setWhereKey(“account_num”, account_num);
             // iterate through resultset collection
             for (int i=0; i< avb.getResultSetRowCount(); i++){
                        System.out.println(“Dump record” + avb.getRow(i));
     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
           Data Access Layer
Contained in com.generic.jdbc package
Responsible for the JDBC SQL execution of
Manages DB Connection pooling for each SQL request.
– 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
  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.
        Data Access Layer (Con‟t)

    Code Example.

    AccountAddressViewBean avb = new AccountAddressViewBean();
    avb.setWhereKey(“account_num”, account_num);
        // 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());
                     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.
      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.
 – 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
      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!
        MVC Framework (Con‟t)
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
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.
         MVC Framework (Con‟t)
ProcessHandler controls the transaction job request processing as
determined by the Transaction XML maps. It provides the three critical
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
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.
       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
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
– MSGResponse is returned by all request handlers containing
  process run-time information.
     MVC Framework (Con‟t)
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.
   MVC Framework (Con‟t)
                  Piecing it all together

   POST request
                     TxnJobHandler                  XML maps
    HTTP                Servlet                     in memory
   JSP returned
                                                        Txn Maps
                     ProcessHandler                     Sql Maps
                       Process Request
                        And Response                    Context Maps

                        Request                   Data Access Layer
Handlers may            Handlers
call EJB classes
for support
                      EJB Processing
              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 EJB 2.0 architecture. All beans use Bean Manage Persistence
(BMP) to leverage existing helper classes and Data Access Layer.
All beans accessible via Entity 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)
        Workflow Framework
There are many open-source workflow frameworks
available such as:
– OS Workflow -
– Open For Business -
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.
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.
– Response defines the post event to perform after the initial
  action is successful.
      There are various response the user can define to trigger events.
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.
Workflow Framework (Con‟t)
Workflow Engine                                                Rule1
                                    Item B to be
                                    Scrubbed by                Rule3….
                                    Workflow YY
Item A to be          Rule2
Scrubbed by           Rule3….
Workflow XX                       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
 may continue or stop if error occurs. Execution State is
 maintained in the database.
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
EJB Container.
Workflow Framework (Con‟t)
All workflow state is persisted in database
All Rule Engine transactions are applied to an
item of processing (i.e. Order line, SCRIPT
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.
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 (