Where’s EMu (at the Canadian Museum of History)?
•Download as PPTX, PDF•
1 like•245 views
Karen Wong, Senior Developer, Axiell (Ottawa)
Recommended
Recommended
More Related Content
Similar to Where’s EMu (at the Canadian Museum of History)?
Similar to Where’s EMu (at the Canadian Museum of History)? (20)
More from Axiell ALM
More from Axiell ALM (20)
Recently uploaded
Recently uploaded (20)
Where’s EMu (at the Canadian Museum of History)?
- 1. WHERE’S EMU? (At the Canadian Museum of History) 1 Axiell Canadian Roadshow May 1, 2018
- 2. THE HISTORY OF EMU AT HISTORY • EMu has been at the Museum for around 20 years • Documents from the original project last modified 1997. 2
- 3. HOW LONG AGO WAS 1997? • The English Patient won Best Picture. • Spice Girl’s Wannabe and Hanson’s MMMbop topped the charts. • The movie Titanic was released. – It would win the Oscar in 1998. • There’s been lots of time for EMu to integrate itself into the museum! 3
- 7. DISASTER RECOVERY PROCEDURE • Mirrored server at the War museum • Nightly job copies the whole EMu installation to a backup across the river. • If something happens, we can switch the licenses and be back up. All it takes is a 5 minute phone call to Axiell. • We no longer have to worry about trees! • Coming soon: multi-site hyper-converged clusters for increased architecture resiliency and redundancy. 74/02/2014
- 8. BEHIND THE WEBPAGES! 8 • Warclipping project • Emuweb objects • Linked to catalogue and multimedia
- 9. BEHIND THE WEBPAGES! 9 • Puppets project • PHP Web 5 objects • Linked to narratives, catalogue and multimedia
- 10. SOME OF THE OLD SITES COULD BE PRETTY SCARY! 10
- 11. WE’RE GLAD THE WEB TEAM GOT INVOLVED! 11
- 12. BUT EMU IS THERE TOO! • New collections page pulls data from IMu API • Web data server contains data for – Old KE-built websites – New CMH-built website • Segregates web environment from production environment • Smaller, flatter subset of fields • Only records marked as “Publish on Web” • Faster and better uptime 12
- 13. IN THE WEBCOPY • EMu Prod. server DRP copy • DRP server Webcopy export • Web data environment IMu API • Json data Web team 13
- 14. WATCHING THE WEB LOADS • Issues with IMu and emuweb mysteriously hanging, with no evidence of what happened. • Normally, if the web data service goes down, we look at the service itself. – Logs produced by emuweb – What queries were running on the pages • But if the load is hanging, it’s not producing logs! 14
- 15. WEB MONITOR PROCESSES • 2 External processes, isolated from the web data services themselves • Pings the service periodically • After 5 consecutives failed responses the monitor restarts the process 15 emuwebmonitor emuweb imuwebmonitor IMu load
- 16. EMU IS THERE IN THE MORNING! 16 BEFORE • DBA logs into every morning • Manually types commands to make sure EMu is ready for users AFTER • Automated process runs as DBA wakes up • Results of checks are waiting in inbox when DBA gets to work
- 17. EMU IS IN CONSERVATION • Conservation details tab • Creates multiple hidden records to track a single conservation task • Each detail can have its own properties including multiple images 17
- 18. EMu is in Exhibitions 18
- 19. EMU IN EXHIBITIONS • Exhibit Objects module tracks properties of an object as it relates to a specific event • Custom client logic auto-populates Levels fields with the names of parent events • More custom logic tracks changes to certain fields: an audit filter catches these changes as the record is saved, and generates this information in a new table. • Exhibit Display and Measurement tabs copy over data from catalogue, but allow you to customize for this event 19
- 21. IN EXHIBITIONS (ONLINE) • Limited web interface for external designers • Search in tree structure based on parent event hierarchy • Displays change history (from the custom change tracking in the thick client) 21
- 23. 23 That means EMu is in the CHH!
- 24. IN ACCESSIONS • Accessions/Deaccessions Project (ADP) moves accessions back into the catalogue • Phase 1 Go-Live Sept 2017 • Process-driven tab design – Each EMu tab corresponds to a step in the Accessioning process 24 Initial order Information Gathering Interest ProposalConsultationsPurchase Meetings Intake Checklist
- 25. IN SAPPHIRE • Many of the tabs recreated in Sapphire for online access • For users who don’t normally use the thick client • Slimmed down workflows 25
- 26. IN SAPPHIRE 26 • New functionality built for ADP forms – Attachments control (not just images) – Pop-out forms allow for “in-form” creation of attachment records • Not available in form builder yet, but can be included in Axiell-created forms.
- 27. INVENTORY TOOL • Record information about multiple pre-accessioned items within the accession lot record. • When the item is accessioned, toggle a radio button to copy the information to a catalogue record. • Once created in the catalogue, the pre-accessioned information is locked. • Retain the link between Accession Lot, the pre-accessioned items, and the object record. 27
- 28. AT LICENSING • Licensing module to track rights and licensing information • Similar workflow-based design concepts to ADP • Tabs and Sapphire designs • But I’ll leave it to our next speaker 28
- 29. SO, WHERE WAS EMU? • Both sides of the river, because of DRP • Behind the websites, powered by the webcopy and monitoring tasks • In conservations • In exhibitions • In accessions • And in licensing • It’s been an eventful 20 years… • Who knows what’s next?! 29
Editor's Notes
- EMu has been installed at the Museum of History, for about 20 years. I know *now*, that the conference flyers says they went live in 1999, but when I asked, nobody could quite remember when… So I went looking for old documents… And I *did* finds some of the original spec documents, from 1997. That’s a really long time! I mean, back in 1997… we were all… well, we were quite a lot younger.
- So, just how long ago was 1997? Well, the English Patient won Best Picture. Chart-topping hits included Wannabe and MMMbop. That was the year that Titanic was released, though it wouldn’t win Best Picture until the following year. There’s been tons of time for EMu work its way into the fabric of the museum. I mean, in that same amount of time, James Cameron has been able to make one and a half Avatar movies!
- So, where *is* EMu in this museum?
- EMu is at history! In fact, I’ve been told that the EMu server about 70 m to my left.
- But it’s also at War! Users from both History and War share the same EMu system, though not always the same tabs and modules. But EMu is also physically present in both locations. That’s because we have two EMu servers on either side of the river.
- We call this the Disaster Recovery Procedure, or DRP for short. 1. Every night, the Production EMu environment, which lives in the History museum, is mirrored across the river to a second server that lives in the War museum. 2. If something happens to the server at History, we can switch the licenses to the server at War and be back up and running in minutes. We don’t have to retrieve and restore backups, and we’ll only lose hours of work. It’s also significant that the two servers are geographically isolated. If there’s a fire in the datacenter at History, we’re still okay. In that scenario, you probably have more pressing concerns, but hey! Your EMu data is secure. It’s one less thing to worry about. 4. We no longer have to worry about trees… The network connection between History and War used to be done by an over the air antenna. We had one instance where the DRP copy failed, and we were unable to determine a cause. We eventually concluded that overgrown trees were interrupting the over the air connection. Thankfully, this antenna has since been replaced by something more reliable. 5. Finally, we’re looking to make the next evolution of DRP this coming year. It involves something called “multi-site hyper-converged clusters”. As I understand it, this means that all the fallover logic and redundancy will be dealt with by the architecture for server itself. This would allow us to stop maintaining two separate servers as all of that copying and switchover logic would be handled automatically.
- EMu is also behind the webpages. There are a number of webpages that serve EMu data to the public. Here is one example. This is the “Democracy at War” webpage, which serves up newspaper articles from the War museum, pulled from the multimedia table.
- Here is another. It uses the PHP Web 5 objects to connect the user to narratives information about puppets.
- Not all the of the old KE sites were very pretty. This one was better known as “that ugly yellow page”.
- So it’s a really good thing that the web team went and replaced it with their own collections search. I think you’ll agree that the current page looks a whole lot better!
- But even the new collections search gets its data from EMu, through the Imu API. We have a separate virtual server whose only purpose is to serve data for the various websites. This means performance issues on one environment won’t affect the other. So if someone’s doing a huge web search, you can still do your work in EMu. Or conversely, if someone’s doing a heavy import on production, people browsing the web page can still get query results. This also means that we can pare down what we’re keeping on the web machine. It has a smaller subset of both fields and records. Records and fields that shouldn’t go online don’t exist at all on the web server, so there’s zero risk of an incorrect query publishing it to the world. The smaller data set means that the web server is faster, and it never has to perform maintenance, so it has much better uptime.
- So, how do we do this? The data for the web server is copied from the DRP machine every night. The data is then massaged and exported to the web data environment. This is where we take out all of those extra records and fields that we don’t need. From there, the web team uses the Imu APi to export the data into json, and they work with the data from that json object. The Network and Infrastructure diagram for all the interactions between our various EMu servers is so complex that it’s been nicknamed the Dead Sea Scrolls. It contains information about the setup for not only the DRP and the webcopy, but also about mounted drives for multimedia and audit. When it’s printed, it has be to printed on a huge sheet of paper. As a result, it is stored rolled up like a scroll in Michel’s office.
- But we’re not quite done with the web yet. We had some issues with imu and emuweb hanging, with nothing in the logs to indicate what had happened, or even that they were down at all. Normally, if a web service goes down, we look at the logs for the service itself, to try and diagnose the problem. But if the process has died, it stops producing logs. So, we had to find a better solution.
- The better solution was to have a external process that watches the web service. There’s one for each web service: emuweb and imu. Each monitor pings its service periodically. After a certain number of pings has no response, it will attempt to restart the service and email the DBA, so we can investigate the problem later. With an external service, we can still *do things* if the web service has crashed. Regardless of why it has crashed: whether it’s a bad query, a bug in the code, or a Russian hacker overloading your website. We can also have some simple diagnosis in the logs. For instance, it will know if the service not visible at all, or just slow to respond. This also allows us to cut back on unnecessary restarts. One of our previous solutions had us restarting the web service every 5 minutes, even if there wasn’t a problem. This maintains uptime, but if a query *just happens* to hit right before the restart, you’re out of luck.
- Before we move on from the system admin section, I want to mention the EMu morning status report. In the summer of 2016, I was on site and someone casually mentioned that a person had to log into the server every morning to make sure EMu was running without any issues before users got in for the day. And also that this had been going on for years. And I said “That sounds really annoying. I’ll bet we can make that better.” We put together a script that runs all those system checks, and added it to the crontab. Then we had the results of those system checks automatically emailed to a few responsible people, in case there’s a problem that needs to be addressed. The other nice thing is that there’s now multiple people getting those emails, so if one person is away, or late, there are other people who know there’s a problem. So, here’s the before and after scenario… Previously, the DBA would log in every morning and manually type the commands to check on the database. Now, the system runs the commands by itself, the DBA gets to enjoy a nice relaxing morning and check the email over his coffee. I really wanted to talk about this because it’s dead simple for us to do. If you’re having the same problem, please don’t hesitate to ask!
- Moving on to the user customizations… A few years ago, we did some significant modifications to the conservation module. I think the biggest change was the addition of the Conservation Details tab. This tab allows multiple processes to be described for a single conservation task. I actually wasn’t involved in the project, so I’ll leave it to people who know it better. If you’re interested, Amanda Gould gave an in-depth presentation on the conservation customizations at the 2015 user conference. I think the slide decks for those presentations are still online.
- Back to a project that I know very well… EMu is in Exhibitions. Specifically the exhibit objects module.
- The first thing we need to talk about is how exhibit objects work in the first place. When you create an event record and add objects to that event, exhibit objects records are automatically created. This allows you to track properties of the object as it relates to that particular event. Maybe you want to specify the location within the exhibit, or the display conditions with the exact lighting that it will be exposed to. Or maybe the measurements in the exhibit will be different from the storage measurements. For example a book might be open to a specific page. All of these things can be tracked in the exhibit objects module. Now, we can get into the specific customizations made to the exhibit objects module at CMH. For the Canada History Hall, the exhibits team created each section of the Hall as a separate events record. They might have an event record for a display case, which would have a parent record of the “Ancient” section of the hall, which would have a parent event record of the Hall itself. It was important to keep track of the entire hierarchy of events records. The first customization that we put in, was some magic to take this hierarchy from the events module and flatten it into local fields in the exhibit objects module. Another change we made was that we implemented an audit filter to track changes in certain fields of the record. If someone changed the status of an exhibit object from pending to accepted or rejected, we wanted to keep a log of who made the change and when. Finally, we made some changes to the display tab (go to next slide)
- I thought this was one of the simplest, and yet effective customizations in the exhibit objects module. The left side of the tab contains fields pulled from the catalogue record. If there are any restrictions in terms of humidity, illumination and temperature on the object record, they’ll show up here. The data from these fields is automatically copied to the right side of the tab when the exhibit object record is created. The information on the right side of the tab can then be edited to reflect “real” exhibit conditions and you can see that data side-by-side with the properties of the object.
- We also created an online web interface for exhibit objects. For the CHH, we had off-site designers who needed to see information about the exhibits, so they were given a web interface which exploits some of the customizations built in the thick client. As you’ll see on the next slide, the parent event hierarchy was translated into a tree search And the change history is shown as if it were a field in the record itself.
- This is a fairly standard default Imu interface. But we have a couple customizations. On the left side, in red, we have the tree structure. Those numbers indicate the number of records at each level of the hierarchy… The standard field by field search is still available under the other icons in the sidebar. Secondly, each record displays its change history, as outlined in green. All of this was specially designed and built for the CHH project, so….
- EMu is also in accessions. We did a project this past year adjusting the Accessions and Deaccessions process to better support the business needs. We went live with Phase 1 in Sept 2017, and will be further refining the design once the users have had a chance to see how it works. We tried to align the design with the process itself. So, each tab roughly corresponds to a step in the accessioning process. Some of the tab names are here, on the right: they’re things like “Initial order”, “Consultations” and “Purchase.”
- Many of these tabs were also created as forms in Sapphire. Some of the people involved in the Accessions process may not be heavy users of EMu, so we wanted to have similar functionality in a simpler and friendlier interface. However, Sapphire was originally designed for much simpler workflows. In some cases, we slimmed down what we needed it to do. For example, we don’t have a way to deal with nested tables, and for now, we’ve just avoided using those. However, we were also able build in some new functionalities.
- There is now an attachments control that allows for adding non-image multimedia files. As you can see, it’s able to live alongside the old image capture control. We also put in “pop-out” forms. This allows users to create an attached record “in-line”. For example, you might be going through this form (this is the information gathering form) and when you try to link in the Source record, you find that there’s no record for that Source yet. You can click on the form icon on the right and it will create a new window containing the Parties form. Once you save the Parties record, it will automatically link your new record back in to the Source field in this form. Without this, you would have to save this record, click out to the Parties form, create your record there, and then come back to this form, search for your new parties record, and then attach it to the catalogue record. This way, it can be done without leaving the original catalogue record. Both of these new functions can now be used in Axiell-built forms, though they’re not yet available as options in the Forms editor.
- The most complicated piece of the ADP project, however, is the inventory tool. The inventory tool is a tab in the catalogue. That is used, for recording the pre--accession information. About objects in an accession lot. Once an item is accessioned, you can toggle the “Create in Catalogue” button and an object record will automatically be created with the same information. This allows us to keep the link between the accession lot record, the pre-accessioned information, now locked, and the new object record. This tab also exists as a Sapphire form.
- Finally, we also went live last year with a project to track Rights and Licensing information. Similar to the ADP, we tried to design tabs and Sapphire forms to support the existing workflow. However, I’m not going to say much about it, since Tanya is going to give an in depth presentation about it.
- So, after all that, where *was* EMu? Both sides of the river, because of the DRP Behind the websites, powered by the webcopy and monitoring tasks In conservations In exhibitions In accessions And in licensing It’s been an eventful 20 years… Who knows what’s next?!