Architectural Design

Architectural Design: ACS E-Procurement Lite Enhancement Steven Crimmins ACS Business Analyst steven.crimmins@acs-inc.com North Carolina E-Procurement (NCEP) • State-wide initiative • Consistent with Governor Easley’s vision of “One North Carolina” for vendors to do business with the State • Initial implementation with NCAS (October 22, 2001) – As of January 2003, over $800 Million in spend through the system; over 20,000 registered vendors, and over 450 catalogs loaded – Electronic access to State Term Contracts – Significant enhancements made since initial implementation including improved search capabilities and system performance • How to leverage current E-Procurement architecture with Colleague – With the Colleague implementation, E-Procurement will now be interfaced to multiple systems with more implementations planned NCEP Transactions • Inbound Transactions (NCEP to CC) – Vendor Updates – Requisitions • Outbound Transactions (CC to NCEP) – Purchase Orders – Invoices • XML Documents/Messages – ASCII text – gXML – Government XML, project-specific – Uses XML Schema Definition (XSD) NCEP Infrastructure Integration Hub • Routes transactions from publisher to subscriber • NCEP Post Office for XML messages Integration Client • Interface to NCEP internal systems • Interface to multiple ERP systems – Colleague – 59 CCs – Sunpac, ISIS – 114 LEAs NCEP Infrastructure NCEP Integration Client • • • • • Written in Java Validates XML documents Communicates status directly with Integration Hub Only one Integration Client per college Uses SSL for security – Port 443 (HTTPS) at startup – Port 50000 for ongoing communication • Uses digital certificates for authentication – Specific to E-Procurement NCEP Integration Client Characteristics • Inbound Transactions – Writes transactions to Inboxes – Sends confirmation of receipt to Integration Hub after transaction is processed • Outbound Transactions – Monitors Outboxes on a scheduled basis (every n minutes, etc.), which is configurable – Receives confirmation of receipt from Integration Hub – Deletes processed transactions from Outboxes ACS Java Applications • ACS EPL Java Middleware – Runs on the same machine as the Accenture Entity Integration Client – Java 1.4.1 Environment – Runs as a NT Service or UNIX Daemon – Log4j for user controllable logging – Secure Socket Connections to ACS Java Colleague Application • ACS Java Colleague Application – – – – Runs on the Colleague Server Populates Staging Tables with Vendor and Requisitions Runs as a UNIX Daemon Log4j for user controllable logging Envision Data Exchange (EDX) • Automated Data Level Triggers – React to data changes from a given state to a new state – XML Based Solution • Uses industry standards – Java, for platform-independence – XML, for data format-independence – HTTPS for security EPL Combined Architecture Inbound Transactions Entity Integ Hub Internet Entity Integ Client Inbox ACS EPL Middleware F I R E W A L L Colleague ACS Java Colleague Appl ERP Server Entity Integration Client PC EPL Combined Architecture Outbound Transactions Entity Integration Hub Internet Entity Integ Client Outbox ACS EPL Middleware Entity Integration Client PC F I R E W A L L DMI Listener Colleague EDX Broker ERP Server ACS EPL Middleware Application Inbound Transactions • Monitors all Inboxes (directories) for transactions (files) • Configurable interval for checking inboxes • Forwards all transactions to ACS Java Colleague Application • Deletes a transaction from Inbox after confirmation of receipt by ACS Java Colleague Application ACS EPL Middleware Application Outbound Transactions • Receives transactions from EDX Broker over secure socket • Writes transactions (files) to Outboxes (directories) • Acknowledges successful writes to EDX Broker ACS EPL Middleware Service Design Considerations • Written in Java for portability • Runs as a system service for reliability – Windows service – UNIX daemon • Minimal recovery considerations – Inboxes/Outboxes act as queues for transactions • Provides for scalability – Integration client and Web server can be separated, if needed or desired ACS Java Colleague Application Design Considerations • Written in Java for consistency • Runs as a system service for reliability – UNIX daemon • UNIObjects Interface to Colleague Staging Tables – External interface for Java to Colleague tables and processes Entity Integration Client Hardware Requirements • Can be same server running WebAdvisor • NCEP Integration Client – Application disk space: 40 MB – Message queue and log space: 60 MB • 2Kb messages, 20K queued messages, 10K logged – 96 MB RAM DMI Server Requirements • Same as Colleague Server • DMI 2.2 • DMI Intermediate Certificate and Utility – Not same as certificate for SEVIS • Java Runtime Engine (JRE) 1.3.1 – http://java.sun.com/j2se/downloads.html • Approved platform for DMI Listener – Sun Solaris 2.7 or 2.8 (SunOS 5.7 or 5.8) • UniData 5.1.36 or higher – Includes UniObjects for Java Administrative Client Requirements • SA Valet 1.02 • Java Runtime Engine 1.3.1 or higher • Connectivity to web server • Connectivity to DMI server Other Requirements • Digital Certificates needed – Entity Integration Client/Web server • Also needed for e-commerce – DMI server • Also needed for other interfaces – Integration Client • Free! • DNS names needed for certificates – Entity Integration Client/Web server (WebAdvisor) – DMI server (Colleague) EPL Enhancement Plan • • • • • • • Currently in development/unit test Enters ACS Internal Quality Assurance mid-April End of May - End to End testing 2nd Week June - User Acceptance Testing End of June - Pilot College Testing (Wayne CC) Begin of July – Pilot College Testing (2nd CC) End of July – Pilot Testing Conclusion EPL Challenges • Workflow Issues – “De-integrating” Colleague purchasing functions – E-Procurement as well as standard Colleague Purchase Orders and Blanket Purchase Orders – Will be addressed by enhancement – Part of training • New Technology – – – – Web-based XML transactions EDX Machine-to-machine processing Questions? Thank You!