Jira Legacy |
---|
server | System JiraJIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | MODKBEKBJ-260 |
---|
|
...
mod-data-export-spring is designed to manage, configure, and run jobs. This module is an entry point to start data export, it calls mod-data-export-worker to execute jobs sending events to the Kafka topic.
What should be done in this module:
- add new export type - 'eHoldings';
- add new request parameters (to ExportTypeSpecificParameters.json), needed to pass export fields, search params for titles search, and other params;
- add new JobCommandBuilder, needed to take request parameters to pass in Kafka event;
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | MODEXPS-94 |
---|
|
...
What should be done in this module:
- create a Reader extending base functionality (CsvItemReader.java, see CirculationLogCsvItemReader.java as an example). The reader should retrieve packages/titles using REST clients, taking search parameters from the incoming Kafka event (from job parameters);
- create a Processor (implementing ItemProcessor). The processor has to take only selected fields for export from the incoming packages/titles. The list of fields for export comes from job parameters;
- create a Writer extending base functionality (we can just use CsvWriter.java if nothing special is needed);
- create a Configuration to build a job and set Reader, Writer, and Processor (see CirculationLogJobConfig.java);
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | MODEXPW-107 |
---|
|
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | MODEXPW-122 |
---|
|
Jira Legacy |
---|
server | System JIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | MODEXPW-108 |
---|
|
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | MODEXPW-111 |
---|
|
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | MODEXPW-112 |
---|
|
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | MODEXPW-113 |
---|
|
ui-eholdings will be able to create and send the export jobs from UI
What should be done in this module:
- when a user clicks on the 'Actions' button, the modal window appears and shows multi-select controls filled with title & package fields.
NOTE: it will be useful to have one task to display only eHoldings fields, and another task to display non-eHoldings fields also;
- when a user clicks on the 'Export' button, UI creates a Job sending a request to mod-data-export-spring:
"methods": [ "POST" ], "pathPattern": "/data-export-spring/jobs", "permissionsRequired": [ "data-export.job.item.post" ], "modulePermissions": []
Request payload follows this schema: https://github.com/folio-org/folio-export-common/blob/master/schemas/job.json
Only "type" and "exportTypeSpecificParameters" are enough to fill in, for example:
{
"type": "equals 'E_HOLDINGS", (required)
, and "exportTypeSpecificParameters" : {
"recordId": "a95bc506-c706-11ec-9d64-0242ac120002", (required)
"recordType": "RESOURCE", (required)
"titleSearchFilters": "",
"packageFields": [ ],
"titleFields": [ ]
}
}
- store the fields available to export (see attached user story);
- see here https://github.com/folio-org/folio-export-common/blob/master/schemas/eholdings/eHoldingsExportConfig.json
- when the export has started, a modal window disapears disappears and the green toast message appears, it shows a the name of generating file, and an approximate duration of export. Duration is defined based on the number of records for export;
We will test the export in various numbers of records to determine what's the approximate duration equal to.
- when a job is completed it contains the link to download the csv file
mod-kb-ebsco-java stores packages & titles, and provides REST API to retrieve these objects. REST methods are already provided for mod-data-export-worker:
Retrieve package details: "methods": ["GET"], "pathPattern": "/eholdings/packages/{packageId}", "permissionsRequired": ["kb-ebsco.packages.collectionitem.get"]
Retrieve package titles (resource): "methods": ["GET"], "pathPattern": "/eholdings/titlespackages/{packageId}/resources", "permissionsRequired": ["kb-ebsco.titles.collection.get"]
Exporting non-eholdings fields
The Tags, Agreements, and Notes are called non-eHoldings because they are stored in other modules. Use the existing API to retrieve a corresponding object.
Agreements - TODO
Tags from mod-tags using CQL - "methods": [ "GET" ], "pathPattern": "/tags", "permissionsRequired": [ "tagspackage-resources.collection.get"]
Notes: TODO
Integration tests
There are no integration tests for the ExportManager module written yet. We will add the folder 'mod-data-export-spring' and create test cases to cover eHoldings export feature
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | FAT-1659 |
---|
|
...