n a new order is completed, the API will notify registered listeners for that event. These listeners can then take appropriate action to propagate the order to downstream systems. Other APIs require that an external program periodically "poll" the system, via the API, to determine if any events of interest have occurred since the last poll. Database Interfaces. Some vendors elect not to provide APIs but instead provide a mechanism to access the application's underlying database. This approach can be implemented in a range of styles. Some are intrusive, where external programs read and write directly to the database using SQL. With others, "objects" in the database are exposed using intermediate tables or stored procedures. The latter technique provides a greater level of integrity and abstraction from the underlying data and enables a more robust and maintainable interface. The former approach can introduce maintenance problems because applications are coupled tightly via database table definitions, which can, and do, frequently change. File-Based Interfaces. Some system designers choose to implement interfaces based on a file import/export paradigm. In this approach, data is imported or exported from the system using pre-defined files and record formats. External systems, wishing to put or get data, request or construct files and records that are imported or exported using a simple API. While this technique may seem dated, it is often effective in situations where the integration is inherently asynchronous, e.g. a feed to the general ledger The Ultimate Guide to Building and Delivering OSS/BSS system after a billing run. This technique can become cumbersome is when more discrete, real-time integration is required. Screen Scraping Interfaces. In some situations, the vendor may not have provided any mechanism to extract or import data or to capture events. In other cases, the vendor may have provided some mechanisms but the breadth of the capability is not sufficient for the required integration. In these situatio