Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

You’ve taken a look at all the benefits of integration with ArchivesSpace and you’re ready to get started with an integration of your own. This resource will take you through a step-by-step guide to integrating with ArchivesSpace, suggest various methodologies for integration and, for those not quite ready for an integration, point to resources for programmatically working with data and systems like ArchivesSpace.

Step-by-Step Guide

Integrate with ArchivesSpace in seven easy steps!

Step 1: Check to see if an integration already exists

Check to see if an integration with a particular system (or the function that system performs) already exists (at any stage of development) or is being planned. The Integrations with ArchivesSpace page on the ArchivesSpace website is a good place to start.

Step 2: Reach out to the community for ideas and/or support

Reach out to the community via the ArchivesSpace Users Group and Member Representatives lists, as well as the ArchivesSpace Google Group, or elsewhere. You may be able to generate additional ideas or use cases for your integration, or even find partners to help with development resources. This process can also help you identify whether the integration you have in mind is generalizable so that it can be used by other institutions.

Of course, the ArchivesSpace Technical Advisory Council Integrations sub-team is also charged in part with “liaising between those developing integrations, the ArchivesSpace Program Team and the ArchivesSpace community,” so we’re happy to generate ideas and/or support as well!

Step 3:  Define the requirements and/or create a specification for the integration

Define the requirements for your integration, focusing especially on “what” needs to happen (“how” it happens can wait for later stages) and/or create a specification that outlines one or more aspects of the work to be done. Here are a couple of examples you can use to model your requirements or specification...

Requirements:

Specifications:

Note: Be wary of any integration that changes your backend database, as it could be hard to keep updated. If your specification requires a change to the ArchivesSpace data model, contact the ArchivesSpace Technical Lead (Laney McGlohon, laney [dot] mcglohon [at] lyrasis [dot] org) for advice, guidance and possible assistance.

Furthermore, if the ArchivesSpace Program Team decides that this integration should be worked into the ArchivesSpace core code, you will need to work closely with LYRASIS, the Organizational Home of ArchivesSpace as well as a Registered Service Provider, and Hudson Molonglo, an ArchivesSpace development partner.

Step 4: Design and develop according to your project specification

Document and, if possible, be open about your process and code, and encourage any third-party partners to be open as well. Likewise, strive to make your integration generalizable so that it can be used by other institutions. These aren’t absolutely necessary, but both are important parts of what it means to be a member of an Open-Source Software community.

If you haven’t already, this is also a good time to plan for the ongoing maintenance of your project after development is completed. How will you ensure that your integration does not tie you to outdated versions of any particular system? How will users reports bugs or request enhancements?

Step 5: Test your integration

As with the two previous steps, testing your integration is an important part of any software development project. Get in contact with stakeholders to ensure that your integration meets the requirements that guided its design and development. You should test your integration with “test” or “fixture” data that closely resembles real data (even “weird” data), for example. Likewise, your integration should: perform its functions efficiently; be usable, even for those that weren’t intimately involved with its design and development; and be able to be installed and run in its intended environments. Of course, test in a development environment first!

Step 6: Go live with a full release!

Hurray! Time to celebrate!

Step 7: Announce the completion of your integration to ArchivesSpace community

ArchivesSpace strives to maintain an architecture that is integration-friendly and the program is always interested in hearing from developers and software projects interested in building connections and integrating their applications with ArchivesSpace. You can start by filling out the ArchivesSpace Integrations Information form so that the Integrations sub-team can learn more about it.

Methodology

ArchivesSpace strives to maintain an architecture that is integration-friendly and the program is always interested in hearing from developers and software projects interested in building connections and integrating their applications with ArchivesSpace. You can start by filling out the ArchivesSpace Integrations Information form so that the Integrations sub-team can learn more about it.

The ArchivesSpace REST API

The ArchivesSpace RESTful Application Programming Interface (API) is a programmatic interface to the ArchivesSpace backend, and consists of a number of exposed endpoints used by the backend server to edit records in the application.

Note: Using the API may be better than doing direct SQL updates to the backend server, as it helps to shield you from accidentally failing to update a related table, creating broken links or using receiving errors when using SQL code written for a previous version of the database.

Software Development Kits

There are a number of ArchivesSpace Software Development Kits (SDKs), libraries that allow ArchivesSpace to interface with a particular programming language, available for developers:

Common Metadata Standards

ArchivesSpace makes use of common metadata standards. Using common metadata standards (or systems that make use of them) such as EAD, PREMIS (and PREMIS Rights Statements), MARC and MODS, as well as content standards like DACS, helps to ensure that your data is portable between systems.

Since an integration necessarily means that you’ll be maintaining data in one or more systems, be sure to think about Systems of Record. That is, you should know which system you’ll turn to as the authoritative data source for a given data element or piece of information.

Not Quite Ready for an Integration?

Perhaps you make use of a number of disparate systems in your workflows, but you're not quite ready for an integration. It may be time to invest in some tools and skills to programmatically work with your data so that you can move data back-and-forth between systems more efficiently. Here are a couple of general and ArchivesSpace-specific resources to get you started...

General:

ArchivesSpace-specific:


  • No labels