ePostRx Architecture - AdvanceNet Health Solutions Inc

townripeΔιαχείριση Δεδομένων

31 Ιαν 2013 (πριν από 4 χρόνια και 9 μήνες)

182 εμφανίσεις

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" 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>




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 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.

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


TxnJobHandler

Servlet

HTTP

XML maps


in memory

ProcessHandler

Process Request

And Response

Txn Maps

Sql Maps

Context Maps

Data Access Layer

Database

Request


Handlers

B2B Processing

Handlers may
call EJB classes
for support

POST request

JSP returned

Interprocess
communication

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

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.

Rule1

Rule2

Rule3….

Item A to be

Scrubbed by

Workflow XX

Rule1

Rule2

Rule3….

WorkflowManager, RulesManager
and ActionManager classes
comprise workflow processing

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).