Write OIH Compliant "Lookup File (At most 1) By Filename" Action

[jhorbulyk]

OIH Standard: In the case of files on an sftp server, the filename with absolute path is effectively the ID.

There should be an action Lookup File (at most 1) that adheres to the OIH standard. Iteration 1 is fine. It is not clear that iteration 2 could ever exist since filename is the only criteria which is commonly used to uniquely identify files. The file should be stored as an attachment in steward and the message structure should be similar to the structure produced by read. The file on the SFTP server should not be altered by this operation.

Suggested Config Fields

• ~Object Type:(dropdown) Currently a single item: file. One day in the future we may add folder.~ -> That make's no sense. Let's keep it as files.
• Allow ID to be omitted (dropdown/checkbox: yes/no)
• Allow zero results (dropdown/checkbox: yes/no)

Input metadata

• One input field for absoute filename + path.

[zubairov]

Interesting proposal. I think the assumption that file name is an ID may not be valid for typical SFTP use-cases where SFTP server is seen lees as CRUD service to read and write data but more like Queue where data batches are temproarily stored

[shulkaolka]

DoD

Component development prerequisites:

• [x] All the branches if the repo should be checked (merged/deleted if possible) before starting development
• [x] Development team has all needed requirements
• [x] Access to the needed service with all needed permissions is granted
• [x] No open tasks that could block Component development process
• [x] The E.io’s GitHub repository must be checked if there is another implementation of the component under development. If it exists, new repository should not be created
• [x] Component architecture should be discussed and approved before start coding
• [x] Component deployment preconditions:
  • Where to deploy (app.elastic.io etc..)
  • Component's access level on each installation that component must be deployed on\

Development:

• [x] Code is written and formatted in accordance with the Styling guide
• [x] Code (incl. configs, test samples, environment variables etc.) MUST NOT contain any sensitive data like passwords, tokens, API keys etc.
• [x] Component logs does not contain any sensitive data (credentials, input/output requests, Environment variables)
• [x] Code is covered with unit tests
• [x] Component code is covered with integration tests (optional)
• [x] Triggers/actions comply with OIH patterns
• [x] Documentation (README.md file in the Github) is 100% ready
• [ ] Changelogs (CHANGELOG.md) are created/updated
• [ ] package.json or build.gradle is updated:
  • Component's version is updated according to Semantic Versioning 2.0.0
• [ ] Component should be dockerised, add: "buildType":"docker" line into component.json
• [x] CI is set up
• [x] All development branches are reviewed

After QA:

• [ ] All development branches are merged into master branch
• [ ] Sprint review preparation is finished (demo flow is built)

QA:

• [ ] Test cases for the component are ready at the TestRail
• [ ] Functional testing is finished
• [ ] Regression testing is finished (optional)
• [ ] Component is deployed to the production stage (app.elastic.io) and/or other required stage
  • Component has a proper access level
  • Required Environment Variables are set
  • Smoke test is finished
• [ ] Release notes is done
• [ ] Component Roadmap is updated
• [ ] Component spreadsheet is updated