search

facet-acq / post-award

Application Service Supporting Entitlement and Administration of Government Procurement Actions
BSD 3-Clause "New" or "Revised" License
5 stars 3 forks source link

Edi Transactions Beginning #47

Closed djfurman closed 6 years ago

djfurman commented 6 years ago

Add interface file processing REST endpoint. Refactor cli command to post interface file details to controller and fire event from central location one file at a time. Add application specific config. Also, resolves #25.

Pull Request

Purpose

Sets the groundwork to process incoming interface files in real time or batch job via time-based cycles. Provides an artisan CLI command to process all pending interface files. Provides a RESTful endpoint to handle new interface files and get details about files received prior. Provides a RESTful API controller to support API functionality with project standards.

Approach

Sets up a REST endpoint to notify the application of interface files to process and a separate CLI command to loop through those files and post them to the REST resource. This provides full flexibility to have S3 events or a crontab process to queue up the interface files.

In order to post the request, the CLI command implements Guzzlehttp's PSR-7.

This application functionality is currently not cumbersome to keep in the post-award project; however, the core functionality of post-award is the tracking and processing of post-award agreements and their actions through the remainder of the supply lifecycle.

Processing of interface files, mapping from source format into post-award's JSON format, posting the result to the post-award application, tracking transactions to interface files and managing the archival of processed interface files is a critical component to interfacing with the dozens of asynchronous EDI based file-based trading partners in the ecosystem, but is legitimately a distinct microservice unto itself. In order to make this split viable, a central gateway should be considered so that a calling client need not consider the service of which they are speaking; but instead, route as needed to the services necessary.

Lessons Learned

Writing REST endpoint tests in Laravel provides a familiar interface through which to pass data. However, assuming that the Guzzle interface matched resulted in frustration.

The Guzzle docs describe the correct process, but for posting a payload assume a PSR-7 (or possibly cURL) vantage point, not Laravel test class. This seems obvious in retrospect, but cost me several hours before realizing that the Guzzlehttp\Psr7\Request object simply needed to be explicitly declared with:

  1. HTML Verb
  2. Endpoint
  3. Headers
  4. Payload (already handled by json_encode($payloadArray)
djfurman commented 6 years ago

Add significant support for system-wide WebSocket messaging. This is accomplished locally using pusher and Laravel's echo library. The Pusher SaaS allows zero management web socket server support and a free tier generous enough to support local testing without cost. It supports end-to-end encryption for broadcasts and subscriptions.