WEM (WIC EBT Middleware) is somewhat of a successor to SWEM (SPIRIT WIC EBT Middleware). There were a lot of lessons learned in the creation of SWEM and soon after its completion new features were desired to streamline management of the system. Some of these changes were in progress when a non-SPIRIT MIS needed similar functionality. The requirements of the other project presented a need to revisit some of the architecture of the original SWEM implementation. It was determined that rather than modifying SWEM to get the job done, we'd create something new. This new project is now known as WEM.
While the targeted functionality of the application is very much unchanged, the method of achieving this goal departs considerably from the prior effort. Or, to put it simply, WEM has a much-richer architecture offering a much deeper level of extensibility and a friendlier - albeit much more vast - configuration platform.
There are a couple of changes to the prerequisites. SWEM was built on an earlier version of NServiceBus. The SWEM required version of this critical piece of server software had a dependency on an underlying database technology called RavenDB. As of version 5.0 RavenDB is no longer required by NServiceBus. WEM no longer requires NServiceBus, thus not requiring RavenDB. See the table below for further clarification.
| SWEM | WEM | |
|---|---|---|
| NServiceBus | 4.7 | N/A |
| RavenDB | 2.0 | N/A |
The configuration framework for WEM is a complete overhaul. While SWEM was built to use multiple configuration files including app.config (2x), web.config, and the TransportConenctionString.config - each with logging and database settings independent of one another - WEM uses only one three total files. One that controls all of the application database settings. One that controls all of the logging settings, and the third which controls all of the application configuration data.
Logging and database connection information, aside from consolidation, remain largely unchanged. However, application configuration is changed dramatically. First, it no longer uses XML (eXtensible Markup Language) based configuration. Instead it uses JSON (JavaScript Object Notation) to power the configuration structure. This approach allows for a much richer configuration. Moreover, in SWEM it was necessary to edit the configuration by hand, but in WEM a tool has been created for managing the file, with plans for an even richer web-based tool in the near future.
Learn more about each configuration structure by visiting the following pages:
SWEM was built in such a way that it was directly coupled to a single SPIRIT instance. Moreover, it was coupled explicitly to SPIRIT. It was also coupled to a single EBT instance, but was built to the Universal Interface 2014 so it could connect to any modern EBT system. In stark contrast, WEM was built to be multi-instance from the onset. In fact, it can support multiple delivery mechanisms such as SOAP or Raw TCP/IP Socket communication. It supported both FTP and SFTP for file transfer from day one. It will allow as many as the hardware will support instance endpoints. With sufficient hardware a single WEM could host 10 or more separate MIS to EBT connections. This is made possible in part by the sophisticated configuration framework built into WEM.
As mentioned above, SWEM had support for one MIS and one EBT connection. This was not conducive to an offline implementation, nor was it ideal for a SEBT (Summer EBT) program. WEM however is route aware allowing it to determine the endpoints to which it can send a message or a file. This is, again, thanks to the rich configuration framework at the heart of the WEM system.
For example, an agency with a summer EBT program could route transactions from two distinct MIS systems to the same EBT system. Or in contrast they could route transactions from a single MIS to two separate EBT systems. Or even route UPC files from MIS 1 to EBT 1 and 2, while everything else just goes to EBT 1. All managed in a single configuration location.
Messages are logged in a way that makes tying the messages back to the original and following the full request/response sequence much easier. As a message from MIS to EBT generates a single transaction, this may result in 3+ transactions on the Middleware to EBT side. SWEM would log these altogether, making tracking a message more difficult. WEM logs these messages using relationships. The MIS view is seen in a Message Log table, and the Middleware view is in the Message Log Details table. The relationship between these tables makes it easy to see which MIS message to which the various Middleware messages relate.