Phase-2:10. Requirement Analysis
- Sharmendra Vishwakarma
- Gaurav (Unlicensed)
1. Business Requirements
As JSD server is quickly filling up storage with the large Imaging files required for the ingest , the Art Institute of Chicago is looking to skip Jira for attaching images files. The final image files should be pulled from imaging server and pushed to NetX. This remains the requirement with highest priority.
There can be new attributes added to CITI api. So, There should be a way to support those new fields dynamically through mapping in the JSD integration
When a “Labwork Non-Collections” request is submitted, generate a ticket per asset ID selected, then group all tickets into an Epic. Pull in NetX metadata for each asset ID selected
For multiAssetType2 (“Labwork - Collections” one form per asset) requests, each Asset ID selected in CITI should open a form, and the Asset ID field in Jira should contain the ID selected in CITI. Then, once each of these forms is submitted, they should relate to each other. This should operate in the same way as multiObjectType2
Each of the autogenerated tickets for the requirements above should pull metadata from NetX
For multiAssetType1 (“Labwork - Collections” single form) requests, generate a “Labwork Sub-task” for each Asset ID selected. Each “Labwork Sub-task” will push an asset (or check in a new version - see requirement #2) to NetX once complete.
Each of the autogenerated tickets for the requirements above should pull metadata from NetX
“Labwork” issue type should have an option to complete the workflow by checking in a version OR pushing a new asset to NetX.
Should there be two transition buttons available? Currently, “Labwork (Collections)” can ONLY check-in a version to NetX. However “Labwork (Non Collections)” pushes new versions. Each of these request types share an issue type which is "Labwork" -- see data flow diagram below for more detailed information.
Should the Imaging request system look for certain data then make a decision to version or create a new asset depending on the data? For instance, Asset ID = null will imply that the file is a new asset and should not be checked in.
“Labwork (Non Collections)” and “Object (Non Collections)” request types are not pushing metadata into NetX when new assets are ingested. The files themselves land in NetX as they should, but metadata is not pushed from the ticket. Errors are returned in the log when we close these types of tickets.
For some reason the Document Type is the only attribute that pushes into NetX for these types of requests
2. Project Goal
Automate the attachment/ingest process between the Imaging server and NetX from JSD.
Integration of JSD with Imaging Server.
New functionality, Enhancements and Bug fixes
3. Scope
Sl No# | Items | Description |
|---|---|---|
1 | Imaging Server Integration | REST API is required to pull the image. |
2 | JSD ( Development of Integration Code) | Development of integration functionality in JSD for Imaging Server. |
4. Out of Scope
Sl No | Items | Description |
|---|---|---|
1 | File name convention | There is no change in file naming convention/rules. |
2 | API Image server development | There will not be any api development work to be done on imaging server |
3 | API development on NETX | There will not be any api development work to be done on NETX server |
5. Architecture
5.1 Overall Architecture
6. Work Breakdown Structure (WBS)
Sl No# | Task | Task Description | Estimated Effort(Hours) | Status |
|---|---|---|---|---|
1 | Image Server Integration Settings | Integration settings UIs/Business Logic |
| Done(In QA) |
1.1 | Development of Connection Settings(UI) | Provision for User to view the connection settings ( Edit/Detail View) | 8 |
|
1.2 | Business Logic to save the connection details | Provision to save the connection settings in db | 8 |
|
2 | Automate Image Ingestion |
|
| Done(In QA) |
2.1 | Business Logic to pull the image from imaging server when issue is closed and pushed to NetX. | Image ingestion logic implementation | 16 |
|
3 | Enhance CITI to Portal api mapping in JSD to support more fields | Provision to support more fields through CITI to portal mappings as they are added to the CITI api response |
| Done(In QA) |
3.1 | Support for new fields added to CITI | Business logic to add provision to JSD through mapping to support fields as and when they are added to CITI api | 6 |
|
4 | New workflow for Labwork Non-Collections | Generate ticket per asset Id, Group all tickets in an epic and pull NETX metadata for each asset Id |
| In Progress |
4.1 | Business logic to group all tickets | Grouping all tickets in an epic | 8 |
|
4.2 | pulling data from NETX | Business logic to pull data from NEXT after the creation of tickets | 8 |
|
5 | New Workflow for Labwork(Collections) - multiassettype2 | This should exactly work like multiObjectType2. NETX information should be pulled after creation of tickets. |
| No Changes Needed |
5.1 | business logic for generating subtasks using decision making fields | business logic to generate subtask based on values selected by users for the decision making fields | 16 |
|
5.2 | business logic to pull NETX information in subtasks | There is already a functionality to pull data from CITI. We have to add function to add data from NETX. | 12 |
|
6 | Bug with Labwork (Non Collections)” and “Object (Non Collections) | Assets are getting pushed into NETX but not the metadata. The only metadata attribute which flows is the document type |
| Done(In Prod) |
6.1 | One of the field is failing due to mismatch in the options between JSD and NETX | Seems like JSD is trying to push the data to a dropdown field which is not present in NETX. It could also be that we have to support a field which is not currently supported | 4(Need to test and see the exact reason. This is a rough estimate) |
|
7 | “Labwork” issue type should have an option to complete the workflow by checking in a version OR pushing a new asset to NetX. |
|
| Done(Completed in local) |
7.1 | Logic to identify customer request from issue type | add custom field on the portal form to identify request type | 1 |
|
7.2 | Business Logic to take decision on what to do after identifying customer request type | Logic on whether to create new asset and push metadata or create new version of existing asset | 10 |
|
8 | New workflow for For multiAssetType1 (“Labwork - Collections” single form) requests | Generate a “Labwork Sub-task” for each Asset ID selected. Each “Labwork Sub-task” will push an asset (or check in a new version - see requirement #2) to NetX once complete. Each of the autogenerated tickets for the requirements above should pull metadata from NetX |
| Done(In QA) |
8.1 | Business logic to create subtasks | Business logic to identify this as labwork and create labwork-subtask and not the other subtasks | 6 |
|
8.2 | checking in assets/creating new version in NETX | business logic to take decision on whether to create asset or create a version in NetX | 8 |
|
8.3 | Business logic to pull data from NETX | Business logic to pull NETX metadata into subtasks | 7 |
|
9 | CITI Request Type and CITI Request Type ID fields do not work when configured in the “CITI to Jira mappings” | CITI Request Type and CITI Request Type ID only work when configured in the “CITI to Portal mappings” page. We would like these fields to be hidden on the portal but have the values set once the issue has been submitted. (We can programmatically hide these two special fields from portal if it is required to be hidden for all the request types. The purpose of “Citi to Jira mappings” is different and it is not going to help us in achieving what we are trying to achieve over here.) |
|
|
10 | Integration Testing & Regression | Integration Testing & Regression | 24 |
|
11 | UAT | User Acceptance Testing | 32 |
|
12 | Prod Deployment | Deployment of code in Production | 1 |
|
13 | Hyber-Care Post-Golive | Hyper-Care Support | 24 |
|
14 | Documentation | Documentation | 1 |
|
|
|
| 200 |
|
New Requirements which were not a part of initial discussion
Sl No# | Task | Task Description | Estimated Effort(Hours) | Status |
|---|---|---|---|---|
1 | Add updates for attachment ingestion and NETX attributes push as comments | Update comments with logs of ingestion while closing a Jira ticket |
| ToDo |
1.1 | Restructuring the code to capture the logs for closed ticket |
| 10 |
|
1.2 | changes required to put an internal comment on the ticket |
| 2 |
|
2 | Replace 360 spin with a configurable multi checkbox custom field | Replacing a decision making field for object type |
| ToDo |
2.1 | Remove support for "360 spin needed?" and replace it with another multi-checkbox custom field |
| 7 |
|
2.2 | Put the configuration in the field configuration screen |
| 1 |
|
| Total |
| 20 |
|
Remaining Hours: 92.75 Hrs as of 10-March-2022
7-March to 11 March: 16 Hrs
14-March-2022 to 18-march: 20 Hrs
Booked Hrs for DC: 40 Hrs
Remaining: 16.75 Hrs will be left out from 92.75 for Prod Deployment and Sanity Check
7. Dependency
Sl No | Items | Remarks |
|---|---|---|
1 | Access of CITI application | We need this access to test the link |
2 | Access of Net X Application | We need this to validate the integration |
3 | Access of CITI Rest API to push the data | CITI app api details |
4 | Access of Net X REST API to push the data | NET X api details |
5 | Access of JSD to test the integration | Access to the client’s JSD server to test the integration(No required for development) |
6 | Availability of Artic team for any queries | Availability of business users |
7 | Availability of Artic team for testing | Availability of business users |
8 | Access to the imaging server | We need access of imaging server and its APIs. |
8. Development Landscape
Development in Empyra Dev Environment → Deploy the Code in QA Instance → Deploy in Production
9. Deliverables
Codebase of integration
Technical documentation
9. Glossary
CITI : Collection Management Application
Net X : Digital Asset Management System
JSD : Jira ServiceDesk
Additional Info
Below you'll find details about the Imaging request system enhancement requests:
Increase the maximum number of tabs which may open for a multi-object ticket to 20 instead of 10. How does this impact performance?
May have performance impact. Suggested for 10. For each multi-object, there is call to citi-app and hence it will have req-res for each and every cal..
Automate the attachment/ingest process between the Imaging server and NetX.
It would be preferable to skip Jira for attaching files, since the Jira server is quickly filling up storage with the large Imaging files required for the ingest
For Exhibition, Non-object, and Object issue types:
The name of the directory will contain the J number assigned to the ticket
Ticket number = IMAGEREQ-123
Directory name = J123
Final file name = J123-int.tif
Pick up any/all "-int" files in the directory for that ticket and ingest them along with the metadata fields into NetX
This accounts for "complex assets" i.e. more than one final file per ticket
For Labwork issue type:
Most labwork orders do not use the J naming convention for the final file name, but the directory uses J numbers to map to the proper ticket. For example:
Ticket number = IMAGEREQ-777
Directory name = J777
Final file name = G134-int.tif and this should ingest into the G folder in NetX
Here is another example:
Ticket number = IMAGEREQ-888
Directory name = J888
Final file name = D567-int.tif which will ingest into the D folder in NetX
Diagram for new Workflow:-
Open Questions:
If a ticket was not initiated from CITI but contains the “CITI request ID” and “CITI request type ID”, will the assets push to NETX the same as if it were initiated from CITI? Do we need anything else in the ticket to replicate the functionality?.
- NETX information is pulled post creation of tickets in Jira(JSD). So, if the ticket contains all the required information then the information from NETX should get pulled automatically irrespective of whether the ticket was initiated from CITI or not.Will NETX data be pulled into a “Labwork (Collection)” ticket if it was initiated from Jira and an Asset ID is provided, or does it need to be initiated from CITI to pull metadata from NETX?
- NETX information should be pulled irrespective of whether it is initiated from CITI or not as long as all the required information is present in the Jira(JSD) ticket.