# Migrating the SFTP transmission protocol to a REST API

## Some Questions

* List of API endpoints
* Documentation / Sample JSON payloads
* Test endpoint / sandbox.
* API Keys testing / production.
* Go live
* Will new API work in parallel with flat file API?
* Who should we contact with inevitable questions?

## notes

Based on our experience with the current interface, here are some exploratory suggestions.

| Capability | Description |
| -------- | -------- |
| Recent BOM, Shipments (past n months) | Check for BOM, Shipment data that we might need to import |
| Kit current timeline status | Check if current kit status is out of sync with Ford |
| Kit-component-serials status | Which component type serials have been accepted / rejected by CDC |
| Component type metadata | Descriptive component name, (eliminate manual entry) |
| Partner PCV list | When new PCV's assigned they can queried and imported. (eliminate manual entry) |
| PCV metadata | Metadata for assigned PCVs (eliminate manual entry). Improve our UI. |
| Check if VIN needs to change before build | remove need for BUILD_START timeline status |
| Auto reformat component serial | Protect against errors when reformatting code is accidentally modified. Eliminate need to update code for future component serials. |
| Custom Save CDC component | Create a simplified endpoint for us to consume. |
| Web hooks | Automatically notify partners on BOM, SHIP, VIN assignments |
| Sandbox | This one is harder.., a static JSON response to rest response payloads?|

## Lessons learned for current flat file interface.

The flat file interface is currently working smoothly.
It was not without it's difficulties.

### Serial Formatting Rules

* Some components have to be reformatted (EN, TR) from supplier based serial before submission.
* This means our code needs to have intimate knowledge of Ford serial formatting rules
* This should be black boxed.
* We submit components + serials, as provided by a supplier and the reformatting is handled as necessary on the Ford side. We shouldn't even need to know that serials need to be reformatted!!

### DCWS SOAP API
* `SaveCDCComponentAsync` arguments not intuitive.
* E.g. what do `AcceptIfVINNotFound`, `AcceptIfWrongComponent`, `AcceptIfInvalidScan` mean? Should it be set to `true`? Will something bad happen? If so what?
* Response payload not intuitive
* For example, what does it mean when `SaveCDCComponentAsync` is submitted with a VIN which was received from the Ford system, and a `VINNOTFOUND` response is received?

### PLAN BUILD status

* Due the situation in Myanmar, `PLAN_BUID` dates diverged significantly from actual `PLAN_BUILD`
* Why can't we change the `PLAN_BUILD` data after it has been accepted by Ford.
* It is confusing for users to juggle the fact that the `PLAN_BUILD` date is not the `PLAN_BUILD` date when looking at the logs.

### BUILD START status

This is the event sent to trigger Ford to check if the previously assigned VIN needs to change.

* `BUILD_START` date must be the same as `PLAN_BUILD` date even if actual assembly starts on a different date.
* In reality the `BUILD_START` has exceeded `PLAN_BUILD` by several months.
* To reduce the cognitive load we have opted internally for: `VERIFY VIN` which is it's true purpose

### Missed window retrieving flat files

The receiving and sending of flat files is an error prone and brittle. Myanmar's intermittent internet as well as other outages have resulted in missed imports.

* BOM / Ship file not imported.
* Limited window in which to get the flat files including BOM / SHIP files
* Once missed we don't event know that we missed.
* Discover missing BOM / SHIP files when the actual Shipment arrives in Myanmar
* Email's required to a specific person in Ford who must write a script to re-run the batch process.
* The regenerated files contain LOTs that have already been imported from previous shpment files! This results in additional coding and testing.

### Partner Status

* Need to understand rules as to when event statuses can be submitted and allowed date ranges.
* No API for obtaining the current timeline status of a kit.
* Need to create a simulation of Fords timeline via snapshots tables in our system.
* No sandbox for testing various scenarios against Fords rules.
* If just one of 200+ entries doesn't sync up with what is in Ford system the whole lot is rejected.
* Cascading delay in assigning VINs which means production downtime.
* The partner status acknowledgment response payload is non intuitive. Takes repetitive explanations. Even then it's still confusing.
* Needs intricate code and unit tests to ensure that a partner status file submission is not rejected.