Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-2737

Bulk APIs for Orders Storage Module

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Open (View Workflow)
    • Priority: TBD
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Template:
      UXPROD features
    • Development Team:
      None
    • Calculated Total Rank:
      22
    • PO Rank:
      75
    • PO Ranking Note:
      Not all institutions will be migrating Orders, and there is a lot of business logic associated, but if it's going to be loaded, it needs to be bulk
    • Rank: Chalmers (Impl Aut 2019):
      R4
    • Rank: Chicago (MVP Sum 2020):
      R4
    • Rank: Cornell (Full Sum 2021):
      R2
    • Rank: Duke (Full Sum 2021):
      R2
    • Rank: 5Colleges (Full Jul 2021):
      R2
    • Rank: GBV (MVP Sum 2020):
      R2
    • Rank: U of AL (MVP Oct 2020):
      R5

      Description

      Current situation or problem:

      In order to facilitate migrations in a timely and efficient manner, the Orders Storage module needs to have batch APIs. POSTing, PUTting and DELETEing records one HTTP request and database commit at a time is unusably slow for large data sets.

      In scope:

      • Bulk Create/Update for PO Lines
      • Bulk Delete (with CQL query parameters) for PO Lines
      • Bulk Create/Update for Purchase Orders
      • Bulk Delete (with CQL query parameters) for Purchase Orders

      Out of scope:

      Batch APIs for acquisitions units, alerts, order templates and prefixes/suffixes are not required. The anticipated order of magnitude for these record sets is not sufficient to require batch handling. The individual record APIs are sufficient.

      Use case(s):

      • Initial Data Migration, including iterative data load/delete

      Comments:

      In order for these APIs to be effective, they need to bypass the business logic and go directly to the storage module. This means that bulk creation of purchase orders will not connect data to the Invoices, Receiving or Finance modules. The user of these APIs is responsible for maintaining data integrity; documentation needs to reflect this.

      Questions:

      Can the Orders module function properly with just purchase orders and PO Lines, or do titles and pieces need to be created as well? If so, then these would probably need bulk APIs, as well.

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                sekjal Ian Walls
                Reporter:
                sekjal Ian Walls
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                  Dates

                  Created:
                  Updated:

                    TestRail: Runs

                      TestRail: Cases