ITAC GIS Extensions and Services
Frameworks
The ITAC Frameworks have been developed over the last 5 years
after many successful GIS implementations. The GIS product
is really a toolkit which provides a set of core components
for building B2B solutions. With this toolkit approach,
GIS provides incredible flexibility, but with flexibility good
development disciplines need to be applied to ensure the solution
meets your needs, is easy to manage, and is extensible for the
future. The ITAC Frameworks provide a generic
suite of components to simplify and speed the deployment of
GIS and have been deployed in a number of organisations throughout
Asia B2B Framework
Why provide a Framework??
- GIS provides 'out of the box' services
for processing and tracking EDI, but not for other formats
(XML, Flat file, Binary)
- GIS provides Correlation system for
tracking, but too generic
-
To provide common tracking
and error handling across all processes
-
To provide common communications
management regardless of protocol
- Reusable Business Processes that
derive their communication settings dynamically
- Provide standardised retry and recover
processing
-
Allow real "Content
Based Routing" (not just EDI) with a Rules based engine
-
Minimise development and
deployment time for new projects
-
Remove the barriers to trade
through implicit trading relationships and minimise system
administration
-
To provide visibility through
a Portal for all messaging in a consistent way, with built
in processes for reprocessing messages
What is the B2B Framework??
- Around 100 Pre-Built GIS Components (BP's, Map's, XSLT,
Services) Generic Communications BP's for FTP, SFTP, Mailbox,
HTTP, AS2, E-Mail, Database, Fax, SIB, JMS, WebSphere MQ,
File-system
- Custom Properties for generic Framework Control
- A Rules engine that allows implicit and explicit rules
to control message processing
- Custom Database tables for Message and Document Logging,
and Rules Engine Supports MySQL, Oracle and Microsoft SQL
Server (2000 & 2005)
- Framework Management Interface (FMI) for managing Rules
- Document Management Interface (DMI) for viewing and managing
Documents that have processed Includes functions for Re-processing
and Re-Sending Messages
The following diagram depicts the Architecture of the ITAC
B2B Framework:
- Receive Protocol Handlers. Triggered
when Messages are received over the various communication
channels. Responsible for providing any additional validation
of the channel (security) and collecting metadata which
may be used later during the process. The Source of the
messages can be your internal business systems or an external
trading partner
- Collect. Scheduled processes to collect
Messages from external Servers (E-Mail, FTP, etc)
- Receive. Responsible for logging information
about the Message to the database. Queries the Receive Rules
to determine if Routing information can be derived from
the communication channel metadata . This allows for the
routing of non-structured data based on message attributes
such as filename, user, etc
- Identify & Split. Responsible for
splitting a Message into individual Documents if required.
It identifies the core Message identification attributes
such as Source, Destination, Document, Format, Standard
and Version and uses these to query the Split Rules. It
passes each Document and its metadata to the Route process.
If the Message if EDI, it de-envelopes the Message (if required)
- Route. Responsible for processing the
document, and logging information about it to the database.
It queries the Route Rules using the Document metadata and
optionally calls the Pre-Process,Core Process, Post-Process
and Send process
- Pre-Process. Optional reusable Business
Processes which can be used to pre-process a Document. An
example would be a process that extracts business information
from a Document (before translation) and saves it to a database
for future reporting
- Core Process. This is an optional core
Business Process applied to the Document. It would typically
verify and/or Translate the Document
- Post-Process. Optional reusable Business
Processes which can be used to post-process a Document.
An example would be a process that replaces or removes certain
characters from the document before it is sent
- Send. This Business Process is optional,
and is responsible for delivery a Message to its ultimate
destination and logging information about the Message Status
to the database. It queries the Send Rules to determine
how to send the Message.
- Post-Send Process. Optional Business
Process that can be configured to do additional processing
after a Message has been sent successfully
- Send Protocol Handlers. The Business
Processes are called to Send Messages over the various communication
channels. Provides retry and recovery logic. The Destination
of the messages can be your internal business systems or
an external trading partner
Error Process. An optional Business Process
that can be called by the Route or Send processes if an error
is encountered. It is additional to the standard Error Handler.
Other Framework Functions
- GIS Mailbox (Optional)
- Provides the core “Store and Forward”
function for managing the sending and receiving of Messages
- Acts as the “Server” for FTP and SFTP
Client connections. Can also interface to Sterling Connect:Direct
- All other non-Mailbox Protocols can make use of the
Mailbox to store copies of any Messages received or
sent
- Partners can use the Mailbox Client GUI to access
their Message History
- Alert Rules
- Allow Error notifications to be routed to selected
parties based on the Document meta-data (Source, Destination,
Document Type) and Error Type
- Portal Interface
- Document Management Interface (DMI)
- Allows for the Searching and Viewing of Documents
processed through the system, Including the raw
data before and after processing
- Standard functions for Re-processing or Re-sending
Messages and Documents which trigger GIS Business
Processes to perform
- Framework Management Interface (FMI)
- CRUD interface for managing the various Rules
tables
Screenshot for Document Management Interface |
Screenshot for Framework Management Interface |
Portal Framework
Why provide a Framework??
- To provide a standard interface between Web Applications
and GIS
- Deployed within GIS (Web Extension) or Deployed on
external Web App Server (HTTP Interface)
- Provide common error processing and return consistent
responses to the Web Application
- Use Rules based triggering of Business Processes
- A common Business Process is called for all Requests
- Standard Request/Response XML messages
- Control Security/Access and provide Audit
- Access to Rules by Community, Application and Action
- Audit Actions by User
- To provide and interface to and from the B2B Framework
(Asynchronous Messaging)
- Utilise a Standardised Development environment based
on Eclipse and other tools
- Develop and test Web Applications that call GIS Business
Processes on separate client machines
What is the Portal Framework??
- A Java wrapper class to invoke GIS Business Processes
- Configuration setting, controls if using GIS Web
Extension (WebX) or HTTP Client method
- Passes standard metadata to Business Processes
- Custom Properties for generic Framework Control
- Rules engine to control which Business Processes are
called for each Action
- Security
- WebX can use JSP Tab Library
- HTTP Method uses Basic Authentication
- Security layer can be provided externally –
User name can be passed in metadata
- GIS Permissions can be used to secure Community,
Application and Action
- Login Action available to return GIS User metadata
The following diagram depicts the Architecture of the ITAC
Portal Framework:
|
