hive-fe-fedex v86.71.3

FedEx Hive

FedEx Hive uses hive-deployment for deployment and development.

Development Options

Below you find instructions for two different development setups:

1. Local host: set up and run the hive servers and all dependencies on your local development machine. You may prefer this option if you value having direct and immediate control over all components.
2. docker: set up and run servers and dependencies in docker containers on your local development machine. You may prefer this option if you value ease of use and reproducibility.

Development on Local Host

Follow the initial setup instructions for hive-deployment but stop before the section "Project Setup" with the yarn commands. Instead of running those yarn commands continue here.

Install Postgres

PostgresApp (<=13) Download

Create Local DB

$ createuser db_admin --login --createdb --createrole --superuser
$ createuser apkudo --login --createdb --createrole --superuser
$ createdb -U db_admin fedex

Install Dependencies

$ cd /path/to/hive-fe-fedex/
$ yarn

Create Secrets File

Ask the team for access to the secrets file .fsc_secrets.json via Keeper. Create a new file ~/.fsc_secrets.json with those contents.

Add pkg_line Entry

In database/migrations/4200_charge.sql, locate this line:

ALTER TABLE pkg.pkg_line_report ADD COLUMN IF NOT EXISTS charged BOOLEAN;

Directly below it, add this line:

ALTER TABLE pkg.pkg_line ADD COLUMN IF NOT EXISTS charged BOOLEAN;

Create Blank PEM File

$ touch ~/fedex_cloudfront_sign.pem

Development Setup

$ yarn dev:setup
$ yarn dev:migrate

Note that the following are expected in development:

@ psql:2310_sku_type_lookup.sql:18: ERROR:  "tmo_sku" is not a materialized view
@ psql:5700_loss_risk.sql:81: ERROR:  "trade_in_offer_value" is not a materialized view

Tunnel Management

$ brew install autossh

Development with Docker

This approach effectively encodes the above setup instructions in docker and docker compose files. The result is very similar to the local-host approach with postgres and the node servers running in containers instead of directly on the host system.

Setting up a Dev Environment with Docker

1. Install docker: https://docs.docker.com/desktop/install/mac-install/
2. Obtain a GitLab CI token and make it available as an environment variable in your shell: https://gitlab.apkudo.com/hive-fe-platform/hive-deployment/blob/master/README.md#registry-setup
3. Create secrets file: see below or https://gitlab.apkudo.com/hive-fedex/hive-fe-fedex/-/blob/master/README.md#create-secrets-file but store it in this (hive-fe-fedex) repository instead of (or in addition to) your home directory.
4. Run docker compose -f docker/compose.yaml build --build-arg EMAIL=YOUR_APKUDO_EMAIL to build the docker container images. This step only needs to be run once. Re-running it is only necessary when there are fundamental changes to the database version or name, the repository structure, or the docker files.
5. Run docker compose -f docker/compose.yaml up to start a fresh instance of the database and the fedex hive services in containers.
6. The reporting interface should now be available at https://fsc.localhost.hiveplatform.org:9210/login

Dev/Test Cycle with Docker

The docker compose setup maps the local hive-fe-fedex repository into hive-dev container. Thus the hive container operates directly on the host's repository contents (not on a copy internal to the container).

• In general, changes to the node codebase can be made visible by restarting the hive container: docker compose -f docker/compose.yaml restart hive. This is a rather heavy-handed approach, though. It re-runs yarn, the dev:setup and dev:migrate yarn tasks, and restarts all services. This likely only necessary when modifying the database schema or dependencies.
• For changes to node code within the hive-fe-fedex repository it is sufficient to restart the respective service in the hive container, for example: docker exec -it docker-hive-1 supervisorctl restart fsc_api

Note that the database data in the db container is ephemeral. When the db container (re-)starts, it comes up with an empty fedex database that needs to be initialized with yarn dev:setup and yarn dev:migrate. The hive container automatically runs these commands by default at startup.

Locally testing package validation process with Docker

1. Log in at https://fsc.localhost.hiveplatform.org:9210/ by clicking the Hive logo, navigate to https://fsc.localhost.hiveplatform.org:9210/user-hub/user, add a Station Manager role to your account, update, and hit refresh.
2. Navigate to https://fsc.localhost.hiveplatform.org:9210/station-config, click the station ID link for MRS-01, then log in by by clicking the Hive logo
3. Log in at test.fsc.hiveplatform.org by clicking the Hive logo. If you are not registered, please see the Test Accounts section.

Test accounts

This section contains information on how to register an account for test.fsc.hiveplatform.org. User accounts in Hive are managed as database entities and accounts with the Hive Account Manager role can create and manage such user accounts. To register an account you can either: 1. Contact a software engineer with a Hive Account Manager role for test, most engineers would have an account and that role; in general, Stephen Mattson, manages accounts for test and prod 2. Or, if you have write access to the test database, you can just create an account yourself by inserting an entry to the account.account table although direct database manipulations should always only be a last resort.

Controlling Services

$ cd /path/to/hive-fe-fedex
$ supervisord --config supervisord.conf
$ supervisorctl status
$ supervisorctl tail -f fsc_web_server
$ supervisorctl shutdown

Interfaces

Reporting Interface

For local development, just click on the Hive logo on the login screen and a user will be created for you.

https://fsc.localhost.hiveplatform.org:9210

Operator Interface

Test Station is added automatically. Browse to this link to register your browser to it. https://pkg-fsc.localhost.hiveplatform.org:9212/login?station=TVZTLTAxQVBLVURP-APK-MVS-01

An operator associated with your GSuite account will need to be added before you can log in. e.g,

INSERT INTO account.account (
  account_type,
  account_full_name,
  account_external_id,
  roles
) VALUES (
  'operator',
  'David Perenic',
  'perenic@apkudo.com',
  '{"Exception Admin"}'
);

Configure for content inspection:

UPDATE account.station SET
content_inspection_enabled = TRUE
WHERE station_id = 'MVS-01';

https://pkg-fsc.localhost.hiveplatform.org:9212 login with Operator ID operator

hivepackage

Setup

$ cd /path/to/hive-fe-fedex/hivepackage
$ python3 -m venv env
$ source env/bin/activate
$ pip install -r requirements.txt
$ python setup.py develop

Fetch Orders (as needed)

$ hive_package_fetch_orders --config configs/local_prod.fsc.py.json

Backend

$ hive_package_pipeline --config configs/dev.fsc.py.json
$ hive_package_stats_pipeline --config configs/dev.fsc.py.json

Refresh MVS (doesn't work in dev, isn't needed)

$ hive_package_refresh_mvs --config configs/dev.fsc.py.json

Test

Identify

In the simulated environment, Identify will pass iff:

• The device is on a STO
• The serial number for the device is scanned as the Cartier label

That Identify will have Make, Model, Color, and Memory set correctly iff the SKU from the order is found in the TMO part master. See: https://tmo.hiveplatform.org/device-hub/device_info

Receipt

Accessory Receipts will all pass unless the SKU starts with "SUP".

For Devices, the following rules apply:

• If the Color in the identify result is not set, receipt will fail with a '99578' error indicating that color must be provided. See above Identify section regarding this value. Hive will then ask thet operator to select the color. If this is provided, subsequent receipts should pass.
• If a single damage is selected for the device of "Damaged Charger Port", a randon Misship error will be generated. This error can be handled in exception processing.
• If a single damage is selected for the device of "Damaged LCD", a random Error will be generated. This error cannot be cleared with a standard receipt (only through 'Received Directly', etc)
• Otherwise, the receipt is successful. The Identify record (see above) is used to make this receipt record more realistic.
  • rdireq_flg and rtnrsncod are set based on selected damages
  • invsts is: AT for sealed devices, Y for JUMP or DRP skus, LT is there are any damages, and RT otherwise.

Clear / Flash / Prep RFA Charge

All will be performed according to the requirements even in the simulated environment. All will pass unless "Fail" is selected in the Dock Device UI.