Download ePostRx Architecture - AdvanceNet Health Solutions

ePostRx System Architecture
Presented by AdvanceNet Health Solutions, Inc.
John Strecker – founder, architect and President
July, 2006
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
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 toolkit.zip 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
JNDI.
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:
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
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
XML Configuration Maps
Transaction 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.
XML Configuration Maps
SQL 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" columntype="AN"/>
<sql-column-attribute column-name="trading_partner_num" columntype="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" columntype="N"/>
</sql-attributes>
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>
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>
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
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);
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));
}
}
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
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.
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);
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());
}
}
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.
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.
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)
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.
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.
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 runtime messages:
– MSGRequest is sent to all request handlers to process the
request.
– MSGResponse is returned by all request handlers containing
process run-time information.
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.
MVC Framework (Con’t)
Piecing it all together
Hybrid framework similar to Struts and PetStore
POST request
HTTP
TxnJobHandler
Servlet
XML maps
in memory
JSP returned
ProcessHandler
Process Request
And Response
Txn Maps
Sql Maps
Context Maps
Interprocess
communication
Handlers may
call EJB classes
for support
Request
Handlers
B2B Processing
Data Access Layer
Database
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)
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.
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.
Each trading partner (location) can have multiple, unique
workflow types assigned, with each workflow containing
multiple assigned rules
Example ‘Dispense’ Workflow Rules
Workflow Framework (Con’t)
Workflow Engine
Item B to be
Scrubbed by
Workflow YY
Item A to be
Scrubbed by
Workflow XX
Rule1
Rule2
Rule3….
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.
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.
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.
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.
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).