[Magda Zacharska] 10:36:18
We have less than 30 min left and I would like to spend this time talking about that and getting your feedback regarding architectural improvements. This is a a big endeavor to make architectural changes, we need to start them early to make sure we have enough time to test it properly.
[Magda Zacharska] 10:36:50
And this will definitely affect the Bulk Edit road map I don't think we will be able to talk about this today.
[Magda Zacharska] 10:36:59
I'm also in the process of updating a Bulk Edit road map, so we will return to to this next time we meet.
[Magda Zacharska] 10:37:10
So why did we decided to make architectural improvements? In Morning Glory when we did performance testing, the goal was to support editing at least 100,000 records?
[Magda Zacharska] 10:37:31
We realize that the architecture does not support that, and the performance is even worse if there are other application using export manager: exporting EDIFACT records, Bursar exprot, or circulation log exports.
[Magda Zacharska] 10:37:59
All of those when they are happening they have an impact on bulk edit.
[Magda Zacharska] 10:38:03
So, after further analysis of the code our Solution Architect proposed we redesign and separate Bulk Edit from Export Manager so that it is not affected by all the other things that are happening while other exports export the data. I added a link to the performance results from Morning Glory, and you can take a look at them when you have a chance.
[Magda Zacharska] 10:38:50
I added the link to the proposed proposed design, and I would like to spend a couple of minutes talking about it. I will not be going into the technical details, but there is one part I would like to spend a couple of minutes on. It's a bulk operation states. Because this describes how the data is being processed.
[Magda Zacharska] 10:39:17How will be processed? They will be several states. Not all of them will be implemented in scope of the Orchid release, but those that will include:New - This is the the moment when the user uploads the identifiers or runs the query.
Retrieving records - This is when the user retrieves the records.So we submitted the the way we want to identify the records, either identifiers or the query, and the records are being retrieved from the storage storage modules. This is the second state.
Saving records - This is the third state. This is the snapshot of the records that you get when you run the query. Those files are written to a CSV file, but this is basically a file that is created in export manager. But we will move this file to the Bulk Edit shared storage. This will be not model internal storage. This will be a storage in S3 Armenia for those who are not using Amazon Web Services. This is the file where it will be stored. This is not the CSV file you are downloading to your local machine. This is something that is still happening in the system.
- Data Modification - This is when the user specifies what changes will happen either in the in-app approach or in the CSV approach for user records.
- Review Changes - This is where the records are being displayed on the are you sure form.
- Apply Changes - This is when the changes are being committed to the records stored in the storage modules. So this is saving the data.
- Suspended - This is one of the statuses that we will not support in Orchid. This will be implemented later, when the user will be able to suspend the bulk edit. This will obviously require further discussion.
- Completed - This is self self-explanatory. It is when the job that was completed with no errors.
- Completed with errors - This is when the job is completed with errors and you will still see the errors in the error accordion.
- Cancelled - We are not going to support canceling jobs in Orchid. This is something to discuss later.
- Scheduled - We are not going to support canceling jobs in Orchid. This is something to discuss later.
- Failed - This is when something went wrong and the operation did not complete.
Image Added[Erin Nettifee] 10:43:08
So this list of statuses is this something that is part of the new design? And is this something that would end up being exposed in the Bulk Edit app or both?
[Magda Zacharska] 10:43:25
Yes. This is a part of the new design, and it will be something that will be exposed in Bulk Edit. We are going to do this by an adding additional tab to Bulk Edit. In addition to the identifier and query tabs there will be the logs tab which will again be driven by permissions.
[Magda Zacharska] 10:44:10
But if you have permission, you can see the logs and the standard filtering by status, by record type, and by type of Bulk Edit operation--if it was Bulk Edit edit or delete. And also when the job started when the job ended.
Image Added
[Erin Nettifee] Okay, So this is kind of like deciding to build our own version of the export manager just for Bulk Edit so that it can be customized to Bulk Edit's particular needs.
[Magda Zacharska] 10:44:53
Exactly. It has a more information. You get more data here.
Image Added
[Magda Zacharska] 10:45:12
So what you have Bulk Edit Operation Type, Record Type, Status, those are the status that we mentioned, who ran it, when it started running, when it ended running , the number of records requested, how many records were were processed., was it the editing in app or Manual/CSV, and Actions. If Actions is empty it means no files were created and no files are available. When you click on the three dots you will have the option to download the files, and you can download each of the files that are being created in the process of of Bulk Editing.
[Erin Nettifee] 10:47:02
Thomas is asking about in the chat about whether the information that we're seeing here would be useful in the export manager. But I am guessing that when this is implemented, there will no longer be Bulk Edit data in Export Manager. It will just be all be encompassed in its own interface.
[Magda Zacharska] 10:47:31
So when we go to the Bulk Edit Operational Statuses there's one part that still happens in the Export Manager. When the records are being retrieved from the back end this is happening in the Export Manager, but the file that is being created is being moved to Bulk Edit shared storage, so the file will not be accessible. You will be able to see that the records are being retrieved, but we will not have those files at all in Export Manager.
[Erin Nettifee] 10:48:11
Okay, that feels a little disjointed to me but I don't know if others have thoughts or on it.
[Erin Nettifee] 10:48:18
I think I would want to be able to see all the stuff just in one app.
[Magda Zacharska] 10:48:25
So you would see all the files in bulk edit. You don't need to go to Export Manager. We can hide whatever is in Export Manager. So it's. not confusing for anyone.
[Erin Nettifee] 10:48:35
I mean this is all kind of abstract, so you I'm not advocating for a particular decision.
[Thomas Trutt] 10:48:56
My big worry about this is are we just moving the problem to another app?
[Magda Zacharska] 10:49:37
First of all, we are not competing for resources in with another applications.That was one of the issues we are facing. The most resource greedy part of Bulk Edit is actually saving the changes to the database and handling those changes accurately. Until Nolana, this has been done by Export Manager, which is not the place where those things should happen. This should be a Bulk Edit responsibility. Does it answer your question?
[Thomas Trutt] 10:50:43
A little bit. I still have a concern. Yes, it's getting more access to the Bulk Edit back end process. Because now it's his own app and it's able to do all this processing on its own. My worries is that it's still going to be competing with Export Manager and other processes, because it's still going to be hitting the same API endpoints on the other internal apps. So it might even compound it, because you now have 2 large apps hitting the same APIs at the same time.
[Thomas Trutt] 10:51:12
I guess I could see where this might make a little bit more sense, because the Data Export App was doing the updates moving that component out of it. And that does make sense. Because why would you have updating data in the actually export App and I see your point that we are hitting the the same like in case of hi, Thomason, holding.
[Magda Zacharska] 10:51:42
So we are. We are hitting the same environment with different apis
[Magda Zacharska] 10:51:51
But this will happen if somebody also exports, or does the oapm H.
[Magda Zacharska] 10:51:58
Or make any other inventory changes. this is not what we can prevent.
[Magda Zacharska] 10:52:06
What we know, however, that if something goes wrong we can identify the module, and we can handle this within a module.
[Magda Zacharska] 10:52:16
One module. and this is a good point. We probably will be coming to this once.
[Magda Zacharska] 10:52:22
We have a a performance test for the in place for the new for the new design.
[Magda Zacharska] 10:52:31
I was told this will resolve our problem with the limit of 10,000 records.
[Magda Zacharska] 10:52:42
At this time we should be able to go up in the number of records we can update through the bulk operation, but this definitely will not be a superb blood for inventory or circulation modules performance.
[Magda Zacharska] 10:53:06
I would like we have some of the minutes left. There is one more mockup that I would like to show.
[Magda Zacharska] 10:53:17
Is those
[Magda Zacharska] 10:53:22
Hi Tim, that have expired because we will be putting the record.
[Magda Zacharska] 10:53:28
The the files, a large number of files in the external in the external storage.
[Magda Zacharska] 10:53:37
We will keep them for a month. So for that bug edits that happen in the previous month, you will be able to access them.
[Magda Zacharska] 10:53:47
But then we will remove them, and the files that were removed will be marked with this information, as you see on the screen, plus unavailable for download, because 30 days have elapsed since the job was run
[Magda Zacharska] 10:54:04
in export manager currently you are getting the Xml error that tells you that the exploration talking elapsed, which is not very user friendly.
[Magda Zacharska] 10:54:15
That's why we decided to go this route to to notify the user that defaults and no longer, and
[Erin Nettifee] 10:54:31
So the 30 days then is hard coded. we can make it.
[Magda Zacharska] 10:54:41
We can make it configurable through the api because if it turns out it's a preferred approach.
[Magda Zacharska] 10:54:52
We will start with hardcoded value of of 30 records 30 days.
[Magda Zacharska] 10:54:58
This was the the value that was at some point proposed for the files that are being generated by data export as well.
[Erin Nettifee] 10:55:06
Does anyone have any comments? Sure, I mean that that and 30 days makes as much sense as anything to me?
[Erin Nettifee] 10:55:12
It might be worth a question to Sisops or to, you know, ebsco hosting or index data, just to get a sense.
[Erin Nettifee] 10:55:21
This, too, what they think of that number and configuration and stuff like that.
[Erin Nettifee] 10:55:27
But here I mean the the stuff that we would have to retain would be things like financial records, and we're just not.
[Erin Nettifee] 10:55:34
That's not what's happening here. so I I think 30 days, I think would would be okay.
[Erin Nettifee] 10:55:40
But it I it's probably worth just asking around
[Magda Zacharska] 10:55:50
So I run this obviously by obscure hosting team.
[Magda Zacharska] 10:55:55
And I do also believe that that may depends on size of the institution.
[Erin Nettifee] 10:56:04
Sure, the large institution that have larger about edits, and they have a larger file size same way.
[Magda Zacharska] 10:56:13
Also want to cop on calls of storing those files because they will be eating much more space than for smaller institution when they have a smaller and smaller file size, they will not be eating that much of this storage space and
[Thomas Trutt] 10:56:35
30 days may be not even required for them. They could go longer without running out of space or incurring costs, for it sounds like this is almost a from what you even just described.
[Thomas Trutt] 10:56:56
Now as this might move around based on the institution, and that would make more sense to have. This is a tenant level setting, or have it as an api endpoint that could be hit.
[Magda Zacharska] 10:57:05
You could say delete all files after the State that could be set as a cron job or something.
[Magda Zacharska] 10:57:11
I, Rather let the user the tenant to specify their grace period and yeah, that would be.
[Thomas Trutt] 10:57:23
That would be my preference, as well but if that's not possible.
[Magda Zacharska] 10:57:27
The second one would be having something that a host hit an Api and say, Remove these files up after this date sounds good.
[Magda Zacharska] 10:57:36
I will bring it up to the to the development team
[Magda Zacharska] 10:57:45
So this is it what I had for today?
[Magda Zacharska] 10:57:49
Do you have any comments, questions.
[Erin Nettifee] 10:57:59
I know how many i've
[Magda Zacharska] 10:58:12
Thank you all, and i'll see you in in 2 weeks and We will start with the roadmap updates.
[Erin Nettifee] 10:58:20
Thank you. Hey, Erin, Can you save that file?
[Erin Nettifee] 10:58:25
Yes, I will save it for you. Thank you. have a good one.