This documentation is in its early stages. It is not very complete or definitive and can be inexact.

What is NumaHOP ?

NumaHOP is a software solution to manage the digitalization process of documents from the import of meta-datas and condition report to the diffusion of the documents. It serves as an intermediary between the digitalization provider, the establishments and the export targets. This is mostly an automated process with occasional manual operations and verifications.

What NumaHOP can do

NumaHOP is composed of modules that can:

• import and convert bibliographic records into DublinCore.
• inspect and validate images and bibliographic records of digitalized documents.
• make condition reports for bundles sent to the digitalization provider.
• use workflow for managing digitalization projects.
• export documents to archiving services or digital libraries.
• produce derived documents like OCR, METS, scaled down images.

NumaHOP is able to automatically diffuse documents in bulk. The platform supported are:

• An SFTP server.
• OMEKA/OMEKAS.
• the CINES.
• Internet Archive.

NumaHOP is also able to be shared between establishments and allows to make conjoint projects.

Installation.

Numahop supports 2 mehtod of installation:

• Dockerised solution.
• Normal installation.

Before the installation process, clone the git repository and cd into it:

git clone https://github.com/biblibre/NumaHOP-code.git numahop && cd numahop

If you don't have maven installed you can run this command:

chmod +x mvnw

And use ./mvnw instead of mvn.

Docker Installation.

The Dockerised solution is easier to get running. More of the installation is automatized.

Dependencies

Please check you have these packages installed before the installation.

docker
open-jdk-17
maven (optional)

In order to launch a local docker build of Numahop you can run the command:

# Using the makefile.
make setup-docker
make build-all

# Running the commands directly
docker build -t numahop-run src/main/docker --target run
mvn clean compile -Pdocker # Optionaly add: -Dfast=true

The -Dfast=true enables a maven profile wich disables tests and checks for faster compilation. If you have errors originating from these checks you can either try to format the code that fails or just use the flag to disable the check.

After this you should be able to find an image named numahop in your local docker instance.

You can run this instance localy by running:

# Using the makefile
make all-up
# Running the commands directly
docker compose -p numahop -f env/main/docker/docker-compose.yml up -d
docker compose -p numahop -f run/main/docker/docker-compose.yml up -d

If you connect to localhost:8080 you should see the login prompt of NumaHOP.

TODO: Document how to change the configuration for the docker instance.

Normal Installation.

Runtime Dependencies.

Now use your package manager to install the necessary runtime dependencies for numahop:

mariadb > 10.*
elasticsearch > 8.*
open-jdk-17
tesseract-ocr-all
libimage-exiftool-perl
imagemagick
libyaz4j (optional)

The libyaz4j dependency is only used by the Z39.50 search queries. If you don't need the Z39.50 queries you can skip this dependency.

Compilation

Build dependencies.

make
maven (optional)
npm (optional)

Then you can run the compilation command for numahop:

mvn package # Optionaly add: -Dfast=true

If you have errors during compilation run mvn -Dfast=true package. It disables all exections non needed to build numahop such as tests, code analysis and formating. Once the compilation succeds a file ./target/numahop-<semver>.war should be present in the directory. Move this file at this path: /opt/pgcn/numahop.war. The name of the war is not important but its location is. Once that is done we can run NumaHOP. It should launch and crash rather quickly.

Database

Now we will create an empty database and a user for numahop. run this suite of commands remplacing the placeholders (db-name, db-user-name and db-user-pwd) for your setup:

mariadb

You should be greeted by this command prompt:

MariaDB [(none)]>

Let's create the database:

CREATE DATABASE <db-name>;

Then the user NumaHOP will use to connect to the database:

CREATE USER '<db-user-name>'@localhost IDENTIFIED BY <db-user-pwd>;
GRANT CREATE, ALTER, DROP, INSERT, SELECT, UPDATE, INDEX, DELETE ON '<db-name>'.* TO '<db-user-name>'@localhost;
FLUSH PRIVILEGES;

Note these are the minimal rights the numahop user needs to edit the database.

You can verify that all the information is well defined by running SHOW DATABASES; and SHOW GRANTS FOR '<db-user-name>'@localhost. NumaHOP uses an orm with a changelog and will automatically create all the tables it needs for you.

Elastic Search

Just install elastic search and folow this documentation. And make sure it is accessible from where you want to install numahop either by localhost or an url.

Mail Server (Optional)

NumaHOP needs a smtp mail server for sending emails. It expects it on the port 25 on localhost without auth and security by default. If you want to use a distant server or change the default settings see in the config chapter.

Numahop Config

See how to configure numahop here. After this configuration step you should have an instance that launches successfully.

If you want to manage Numahop using systemd.

Create the file /etc/systemd/system/numahop.service with the content:

[Unit]
Description=NumaHOP
After=syslog.target

[Service]
ExecStart=/opt/pgcn/numahop.war # --spring.profiles.active=... for activating certain profiles
SuccessExitStatus=143
StandardOutput=null
User=numahop # The user to use 

[Install]
WantedBy=multi-user.target

Then use:

systemctl daemon-reload # After adding/modifying the file
systemctl start numahop # For starting numahop
systemctl stop numahop # For stoping numahop

If you don't have root privileges you can instead create the file ~/.config/systemd/user/numahop.service with the content:

[Unit]
Description=NumaHOP
After=syslog.target

[Service]
ExecStart=/opt/pgcn/numahop.war # --spring.profiles.active=... for activating centrain profiles.
SuccessExitStatus=143
StandardOutput=null

[Install]
WantedBy=multi-user.target

And instead use:

systemctl --user daemon-reload # After adding/modifying the file
systemctl --user start numahop # For starting numahop
systemctl --user stop numahop # For stoping numahop

If everything worked correctly you can access the numahop graphical interface by connecting to your server. You can now go to the Post-Installation chapter.

NumaHOP Configuration.

NumaHOP is configured in yaml files called application.yml or application-<profile>.yml.

When NumaHOP is started it search and load configs in this order:

• Inside the packaged war/jar ressources.
• In the folder ./config(relative to its current directory).

Profiles

There can be multiple files sourced by NumaHOP with a profile system. First the application.yml is sourced and then the profiles one. Each load overrides the keys redefined.

To activate a profile the flag --spring.profiles.active can be passed to the war:

# Launch numahop with the profiles dev and prod activated. The keys defined in a later profile overide the keys defined in a previous one.
./numahop.war --spring.profile.active=dev,prod

The resulting files will be sourced in this order:

• Inside the war:
  • application.yml
  • application-dev.yml
  • application-prod.yml
• In the working directory:
  • ./config/application.yml
  • ./config/application-dev.yml
  • ./config/application-prod.yml

application.yml

Most of the properties in the yaml files are used either by spring-boot or other dependencies but some are custom. All uses of custom properties can be found in the codebase using this command: grep -e "@Value\(\$\{.*\}\)".

Important/UseFull properties to define

Instances

Each establishments using numahop must be declared, choose an id for each libraries using Numahop and sotre it there.

instance:
    libraries: lib1, lib2, lib3

Admin

The admin is the only account present after the installation. It is very important to define:

admin:
    login: # default: admin
    password: # Important to override. default: hash of "password"

The password is encrypted using the bcrypt method you can get a good password to encrypt like this:

head /dev/urandom | tr -dc "a-zA-Z0-9"| fold -w 20 | head -n 1

Then encrypt it with a bcrypt implementation. But pay attention not all bcrypt algorithms are secure. The easiest way to encrypt the password is as such it requires a python3 installation with the python3-bcrypt library:

echo "$pwd" | python3 -c <<PYTHON
import bcrypt, getpass;
print(bcrypt.hashpw(input().encode(), bcrypt.gensalt()).decode())'
PYTHON

Where pwd is you password.

Jhipster Remember Me key

This is the key needed to make the rememberme service work. It needs to be unique to your installation.

jhipster.security.rememberme.key: # No defaults must be defined.

Same as the password you can get a good randomized key like this:

head /dev/urandom | tr -dc "a-zA-Z0-9"| fold -w 20 | head -n 1

Database and elasticsearch

The information needed by numahop to connect to the database and elasticsearch.

spring:
    datasource:
        url: # The url to access the mariadb data base often: jdbc:mariadb://localhost:3306/<db-name>
        username: # The database user
        password: # The database password
    elasticsearch:
        uris:
            - <uri> # default: http://localhost:9200
            # ...

Filesystem

These configuration options define where numahop can find the executables it needs, where to put the various files it generates and where to look for files to import.

base-path: #default /opt/pgcn

imageMagick:
    convert: # default : /usr/bin/convert
    identify: # default : /usr/bin/identify

exifTool:
    process: # default : /usr/bin/exiftool

tesseract:
    process: # default : /usr/bin/tesseract

storage:
    binaries: # default : ${base-path}/DAM/DAM_Repository

nativeLibraries:
    path: # default : /opt/svcmgmt/lib

messaging:
    template:
        path: # default : ${base-path}/Messaging/MessagingTemplate


uploadPath:
    condition_report: # default : ${base-path}/upload/condition_report
    ead: # default : ${base-path}/upload/ead
    import: # default : ${base-path}/upload/import
    library: # default : ${base-path}/upload/library
    user: # default : ${base-path}/upload/user
    template: # default : ${base-path}/upload/templates

export:
    ssh:
        knownHosts: # default : ${base-path}/config/known_hosts

services:
    cines:
        aip: # default : ${base-path}/cines/aip
        cache: # default : ${base-path}/cines/cache
        xsd:
            sip: # default : ${base-path}/xsd/sip.xsd
    archive:
        alto: # default : ${base-path}/archive/alto
        text: # default : ${base-path}/archive/text
    metaDatas:
        path: # default : ${base-path}/metadatas
    deliveryreporting:
        path: # default : ${base-path}/deliveryReporting
    omeka:
        cache: # default : ${base-path}/omeka/cache
    ftpexport:
        cache: # default : ${base-path}/ftpexport/cache
    digitalLibraryDiffusion:
        cache: # default : ${base-path}/digitalLibraryDiffusion/cache

Server

The port used by numahop on the server.

server:
    port: # default: 80

Instance

In the instance section we can configure the different libraries using this instance of numahop.

instance:
    libraries: lib1, lib2, lib3

Image Sizes

images:
    format:
        default:
            thumbHeight: # default: 150 
            thumbWidth: # default: 150
            viewHeight: # default: 1417
            viewWidth: # default: 982
            printHeight: # default: 2835
            printWidth: # default: 1964

Cron jobs.

Some services are annotated with @Scheduled. These are cron jobs configured in the cron section:

cron:
    removeOldTokens: # default: 0 0 0 * * ?
    cleanLocks: # default: 0 30 0 * * *
    rebuildIndex: # Rebuild elastic search index. default: 0 40 0 * * *
    cleanDeliveryFiles: # default: 0 0 1 * * ?
    cinesExport: # Try to export eligible document units to the CINES. default: 0 30 1 * * ?
    localExport: # Try to export eligible document units via SFTP. default: 0 0 4 * * ?
    cleanTemporaryFiles: # Clean up temporary files for each library. default: 0 0 2 * * ?
    internetArchiveExport: # Try to export eligible document units to Internet Archive. default: 0 26 17 * * ?
    gestDeliveredFiles: # Save or delete the archived documents. default: 0 00 18 * * SAT
    cinesUpdateStatus: # Download status of CINES export from the mailbox. default: 0 10 * * * *
    omekaExport: # Try to export eligible document units to an Omeka instance. default: 0 0 3 * * ?
    cleanExportCaches: # default: 0 30 6 * * ?
    docUnitUpdateArk: # Retrieve Internet archive urls of archived documents. default: 0 0 6 * * ?
    digitalLibraryExport: # default: 0 0 3 * * ?

The value is a cron expression used to configure when to run the job.

Mail

spring:
    mail:
        host: # default: localhost
        port: # default: 25
        user:
        password:
        from: # default: contact-numahop@numahop.fr
        tls: # default: false
        auth: # default: false
        activated: # default: false

Post installation

Now you have an installed and working numahop instance. But the base installation of numahop is rather empty. The first thing you must create before anything else is the libraries declared inside the yaml configuration files.

Here is a list of things you might want to create:

• User Groups and Users
• Workflow Models
• Contidion Report
• Mail Templates
• Export Configurations
• Bibliographic Records mappings
• Automatic Controls settings

Adding a Library

For each libraries declared create a library through the interface. Then you need to edit the libraries inside the database to make the column identifier match the names declared inside the yaml files. If the library you created isn't defined in the yaml file you need to edit the yaml file and add an identifer to it and restart numahop.

-- Print all the libraries you declared through the interface.
SELECT name FROM lib_library\G
-- Modify the identifier 
-- <lib-identifier> corresponds to the identifier set inside the yaml file.
-- <lib-name> corresponds to the name given to the library at the creation in the web interface.
UPDATE lib_library SET identifier='<lib-identifier>' WHERE name='<lib-name>';
-- Note it is ok to filter by the name as NumaHOP normally enforces it to be unique. 

Once the libraries are created you can create the rest of the objects you need for your use of NumaHOP.

If you have created other objects before the library column update here is how to fix it:

-- Check and note what is the identifier generated by numahop by default.
-- <old-uuid> is what it is referenced as from now on.
SELECT identifier from lib_library WHERE name='<lib-name>';

-- We need to disable the foreign key contraints checks while modifying the libraries otherwise 
-- the contraints will prevent the modification because other tables reference this identifier.
SET FOREIGN_KEY_CHECKS = 0;
UPDATE lib_library SET identifier='<lib-identifier>' WHERE name='<lib-name>';
SET FOREIGN_KEY_CHECKS = 1;

-- Print all tables corresponding to created objects that have a library field and have rows.
SELECT c.TABLE_NAME from information_schema.columns c JOIN information_schema.tables t
ON c.TABLE_NAME = t.TABLE_NAME WHERE c.COLUMN_NAME = 'library' AND t.TABLE_ROWS >=1;
-- For each table corresponding to the created object fix the foreign key.
-- <old-uuid> is the value we 
UPDATE <talble> SET library='<lib-identifier>' WHERE library='<old-uuid>';

First user and user groups

I advise you create a admin user profile with all rights allowed for each libraries as the admin account configured in the yaml file can do some of the things but there are a lot of functionality that are disallowed on this account.

You can also create user profiles that suits your needs.

WorkflowModel and workflow groups.

Mappings

FtpConfiguration

Projects and lots

Imports

Needed for preforming a delivery.

Delivery

NumaHOP Architecture

flowchart LR

    subgraph fr[Angular Front-End]
        direction TB
        fr-view[View] 
        fr-ser[Services]
    end

    smtp[Mails]
    subgraph be[BackEnd]
        direction LR
        subgraph java[Java Application]
            direction LR;
            cont[Rest Controllers]
            ser(Services)
            rep[Repository]
        end
        es[(Elastic Search)]
        db[("MermaidDB")]
        fs@{ shape: lin-cyl, label: "disk storage"}
    end
    subgraph exp[Export Targets]
        direction LR
        omeka[Omeka]
        cines[Cines]
        archive[Internet Archive]
        sftp[File Transfer]
    end
    fr-view <--> fr-ser
    fr-ser <--> |REST API| cont

    cont <--> ser 

    ser <--> smtp
    ser <--> rep 
    ser <--> |Export Protocols| exp

    rep <--> db & es & fs

NumaHOP Data Input/Output

Usefull external documentation

• angularjs
• springboot

Code organization and structure.

Back-End

The root of the back end code is located at src/main/java/fr/progilone/pgcn.

The logic is split up in two ways. Firstly the logic is split vertically in the stack by repositories, services and controllers (in ascending order) these are stored inside folders in the root:

• repositories: Abstraction of storage methods. Can be stored inside the database or the file system.
• services: Core of the business logic.
• web: REST API containing the controllers. Makes the interface to the front-end.

Then the logic is split horizontally by modules operating on a specific primitives. Most of them are pretty straight forward. All the modules are:

• es: ElasticSearch module.
• user: users and their abilities (rights). The authentication is not handled there.
• train:
• lot:
• library:
• *configuration: Modules managing dynamic configurations (configuration that can be edited at runtime).
• workflow:
• delivery:
• document:
• statistics:
• exchange: archiving and diffusion of the document units.
• sample: Module managing the sample mode of digitalized documents. (No reason of being a separated module refactor needed).
• check: Module managing automatic checks (Not triggered or performed by users).
• help: Module managing the help page content.
• imagemetadata:
• multilotdelivery:

There are also other folders in the root which store various configurations as java classes:

• security: The configuration of spring security to allow login and
• config: All configuration classes.

The last folder in the root is the domain folder containing the data models organized by modules representing the different object stored in the database. We can also find additional classes in the folders dto and jaxb. The ones in dto are suffixed with DTO which are objects sent by the Controller (here a REST Controller) to the View (the front-end) and those contained in jaxb are pre-generated classes from schema definitions of the metadata formats used.

Front-End

The front-end root is located at src/main/webapp.

The majority of the functionality is in the folder script.

The DocUnit Module

This module manages document units.

Module files

Domain Objects:

Services:

Controllers:

Manages document units.

The Workflow Module.

In this module the primitive we operate on are workflows. In NumaHOP workflows are tracking the life-cycle of document units.

A workflow is constituted of states. Each states is either processed automatically or require some user interaction in order to be processed. Some states are process automatically and don't require much user interaction such as the Diffusion, Archiving, Automatic Checks, or Delivery Waiting.

Once the condition required for the state to validate the workflow completes it and start the next state. Some states can also be processed in parallel such as diffusion and archiving states.

The workflow is configured with a workflow model. The workflow model to use on a document unit is configured either on the project, the lot, the train. It can also be defined on the document unit itself. If a workflow model is not present it will inherit the model of the parent document unit grouping. (project -> lot -> train -> document unit)

Order of states

• DOCUMENT_INITIALISATION
• SLIPS_GENERATION
• VALIDATION_CONDITION_REPORT
• VALIDATION_SLIPS_CONDITION_REPORT
• CONDITION_REPORT_BEFORE_DIGITIZATION
• WAITING_FOR_DIGITIZATION
• CONDITION_REPORT_AFTER_DIGITIZATION
• WAITING_FOR_DELIVERY
• WAITING_FOR_AUTOMATIC_CHECKS
• WAITING_FOR_QUALITY_CONTROL
• DOCUMENT_PREREJECTION
• DOCUMENT_PREVALIDATION
• DOCUMENT_VALIDATION
• BIBLIOGRAPHIC_RECORDS_VALIDATION
• CONTROL_REPPORTS
• DOCUMENT_ARCHIVING
• DOCUMENT_BROADCAST
• DOCUMENT_BROADCAST_OMEKA
• DOCUMENT_BROADCAST_DIGITAL_LIBRARY
• DOCUMENT_BROADCAST_LOCAL
• CLOSING_DOCUMENT

Special state as it is manually inserted in the workflow in case of a rejection of the state DOCUMENT_PREREJECTION:

• WAITING_FOR_REDELIVERY

Each states holds a status:

• NOT_STARTED
• PENDING
• FINISHED
• CANCELED
• FAILED
• TO_WAIT
• WAITING
• WAITING_NEXT_COMPLETED
• TO_SKIP
• SKIPPED

Module files Domain objects: Domain Ojects:

• WorkflowModel
• WorkflowGroup
• WorkflowStateModel
• WorkflowStateKey
• WorkflowStateStatus
• DocUnitWorkflow
• DocUnitState (abstract class).
• All states classes implementation.

Services:

• WorkflowModelService
• WorkflowModelStateService
• WorkflowService
• DocUnitWorkflowService
• WorkflowGroupService
• WorkflowGroupValidationService
• UiWorkflowService
• UiWorkflowGroupService
• UiWorkflowModelService

Controllers:

• WorkflowController
• WorkflowGroupController
• WorkflowModelController

Workflow are created on a document unit when the workflows are started on the lot level. But once a workflow started its steps can't be modified. When creating a workflow we use a workflow model. Workflow models are a template of a workflow. Each state has different statuses when

API auto documentation.

Note: The open-api auto documentation is incorect because NumaHOP doesn't respect the open-api specification causing some handlers to be merged into one in the documentation. This will be fixed when the api is redesigned see #8.

• Open Api documentation
• Scraped documentation

Contributing to numahop.

If you plan to contribute to numahop you might want to read the coding guidelines.

Developpement environement.

The easiest way to test developpements locally is to use the dockerised version.

The makefile makes management of the developpement loop rather easy. You can see the full list of rules provided by the Makefile by running make list. If you chose to use the docker you should run make setup-docker before running make build-docker.

You can see the NumaHOP logs with make app-logs.

Also the formating of both the front-end and backend is handled in the makefile with make fmt.

The lifecycle of the composition is manage with app-<action> and env-<action> rules. The actions provided by the makefile are:

• up: Start all containers and start their services.
• stop: Stop the services keeping the containers up.
• down: Stop the containers.
• clean: Same as down detaching the volumes allowing for their deletion.

The makefile also provides ways to manage the mounted volumes in the docker images. For example:

• to reset the db you can run make reset-db.

• to get a clean reinstall of Numahop make reset-all. Note the volumes can only be reset by unmouting them from the containers.

Glossary

All definition for terms and acronyms used in this documentation.

PGCN: Plateforme de Gestion de Contenu Numérisé. Original name of NumaHOP.

OCR : Optical Character Recognition. Process by which text is recognized on images.

Metadata standards and file formats.

METS : Metata-Data Encoding and Transportation Standard. An XML standard .

EAD : Encoded Archival Description.

DC : DublinCore. Small Set of core metadata for bibliographic units. User Guide

SIP : Submission Information Package. A file describing a package to be archived.

AIP : Archival Information Package. A file representing an archived packaged.

XSD : XML Schema Definition. An XML file describing an XML format allowing an XML parser to verify a file is well formed according to a standard.

MARC: Format for bibliographic data. Spec

ALTO : Analyzed Layout and Text Object.

Protocols.

OAI-PMH : Open Archives Initiative Protocol for Metadata Harvesting Spec

Z39.50 : A protocol to searching and retrieving data in databases between servers over TCP/IP.

NumaHOP Vocabulary.

Digitalization service provider: The company(for external digitalization) or service (internal digitalization) doing the digitalization process.

Document Unit: Also referred as Doc Unit or DU. A Document or part of a document for collections to be processed by NumaHOP.

Workflow: Steps the Document Unit takes trough NumaHOP. Can be defined at the project level, or the bundle level.

Notice: Bibliographic meta-datas attached to a DU.

Condition Report: A check of the state of the document after it was manipulated during the digitalization process.

Delivery: The step where the digitalized documents are deposited into NumaHOP and attached to the correct Document Unit.

Import: The step where we create the Document Unit.

Grouping of Document Units.

Project: A project is usually a set of documents to be digitalized by the same provider.

Bundle: A physical set of Documentary Units averaging around 20 to 50 documents.

Train: As in digitalization train. Smaller set of document for insurance reason.

All sets of grouping are not necessarily useful for all use cases. For smaller volume of documents in a project the train is not as useful.

Design Pattenrn jargon.

DTO: Data Transfer Object an object traveling between the view and the controller.

Service: Class containing business logic.

Repository: Class abstracting a storage method (database, elasticsearch or file system).

Mapper: Class performing mapping from a domain object to another.

Contributors

Tech'Advantage: Developpement of Numahop from the initial version.

Persée: Dockerisation of Numahop.

Color palette

Old documentation.

Here you can find the old documentation of NumaHOP writen by Tech'Advange also previously known as Progilone. These pdf manuals are more intended for a user than a developper but are still usefull.

These manuals are written in french.

• MAN002 Administrator Manual
• MAN003 User Manual
• MAN004 Provider Manual
• MAN005 Complete Processus

This documentation is in major party wrong because the swagger generates an incorrect api.json due to the api non-compliance to the oas v3.1 spec.

Modules

Account

/api/rest/reset

POST

Parameters: NONE

Body:

Responses:

/api/rest/account/change_password

POST

Parameters: NONE

Body:

Responses:

/api/rest/authenticate

GET

Parameters: NONE

Body: NONE

Responses:

/api/rest/account

GET

Parameters: NONE

Body: NONE

Responses:

Admin logs

/api/rest/downloadlogsfile

GET

Parameters:

Body: NONE

Responses:

Audit delivery

/api/rest/audit/delivery

GET

Parameters:

Body: NONE

Responses:

Audit doc unit

/api/rest/audit/docunit/{id}

GET

Parameters:

Body: NONE

Responses:

Audit lot

/api/rest/audit/lot

GET

Parameters:

Body: NONE

Responses:

Audit mapping

/api/rest/audit/mapping/{id}

GET

Parameters:

Body: NONE

Responses:

Audit project

/api/rest/audit/project

GET

Parameters:

Body: NONE

Responses:

Audit train

/api/rest/audit/train

GET

Parameters:

Body: NONE

Responses:

Authorization

/api/rest/authorization

GET

Parameters: NONE

Body: NONE

Responses:

/api/rest/authorization/{identifier}

GET

Parameters:

Body: NONE

Responses:

Automatic check

/api/rest/check/auto

GET

Parameters:

Body: NONE

Responses:

Bibliographic record

/api/rest/bibliographicrecord

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/bibliographicrecord/{identifier}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

/api/rest/bibliographicrecord/{id}

GET

Parameters:

Body: NONE

Responses:

Check configuration

/api/rest/checkconfiguration

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/checkconfiguration/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

/api/rest/checkconfiguration/{idDocUnit}

GET

Parameters:

Body: NONE

Responses:

Check

/api/rest/check

GET

Parameters: NONE

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/check/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body:

Responses:

/api/rest/check/pdf/{id}

GET

Parameters:

Body: NONE

Responses:

/api/rest/check/lot_pdf/{id}

GET

Parameters:

Body: NONE

Responses:

/api/rest/check/lot_csv/{id}

GET

Parameters:

Body: NONE

Responses:

/api/rest/check/csv/{id}

GET

Parameters:

Body: NONE

Responses:

Check slip configuration

/api/rest/checkslip_configuration/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

Cines language code

/api/rest/conf/cineslangcode

GET

Parameters: NONE

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

Condition report attachment

/api/rest/condreport_attachment

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body: NONE

Responses:

/api/rest/condreport_attachment/{id}

GET

Parameters:

Body: NONE

Responses:

/api/rest/condreport_attachment/{identifier}

DELETE

Parameters:

Body: NONE

Responses:

Condition report

/api/rest/condreport

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body:

Responses:

/api/rest/condreport/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body: NONE

Responses:

/api/rest/condreport/{identifier}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

/api/rest/condreport/pdf

GET

Parameters:

Body: NONE

Responses:

/api/rest/condreport/csv

GET

Parameters:

Body: NONE

Responses:

Condition report detail

/api/rest/condreport_detail

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body: NONE

Responses:

/api/rest/condreport_detail/{identifier}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Condition report slip configuration

/api/rest/condreportslip_configuration/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

Csv mapping

/api/rest/csvmapping

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/csvmapping/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Delivery configuration

/api/rest/delivery_configuration/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

Delivery

/api/rest/delivery

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/delivery/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

/api/rest/delivery/pdf/{id}

GET

Parameters:

Body: NONE

Responses:

/api/rest/delivery/lot_pdf/{id}

GET

Parameters:

Body: NONE

Responses:

/api/rest/delivery/lot_csv/{id}

GET

Parameters:

Body: NONE

Responses:

/api/rest/delivery/csv/{id}

GET

Parameters:

Body: NONE

Responses:

Description property

/api/rest/condreport_desc_prop

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/condreport_desc_prop/{identifier}

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Description value

/api/rest/condreport_desc_value

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/condreport_desc_value/{identifier}

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Digital document

/api/rest/digitaldocument/{identifier}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body:

Responses:

/api/rest/digitaldocument

GET

Parameters:

Body: NONE

Responses:

Digital library configuration

/api/rest/conf_digital_library

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/conf_digital_library/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Digital library diffusion

/api/rest/export/digitalLibrary

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body: NONE

Responses:

Doc property type

/api/rest/docpropertytype

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/docpropertytype/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Doc unit

/api/rest/docunit

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body:

Responses:

/api/rest/docunit/{identifier}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

/api/rest/docunit/initHistory

GET

Parameters:

Body: NONE

Responses:

Export cines

/api/rest/export/cines

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body:

Responses:

/api/rest/export/cines/{id}

POST

Parameters:

Body:

Responses:

/api/rest/export/cines/{identifier}

GET

Parameters:

Body: NONE

Responses:

/api/rest/export/cines/regenerateMets

GET

Parameters:

Body: NONE

Responses:

Export

/api/rest/export/rdfxml

GET

Parameters:

Body: NONE

Responses:

/api/rest/export/ead

GET

Parameters:

Body: NONE

Responses:

/api/rest/export/csv

GET

Parameters:

Body: NONE

Responses:

Export ftp configuration

/api/rest/exportftpconfiguration

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/exportftpconfiguration/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Export internet archive

/api/rest/internet_archive/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body:

Responses:

/api/rest/internet_archive

GET

Parameters:

Body: NONE

Responses:

Export omeka

/api/rest/export/omeka

GET

Parameters:

Body: NONE

Responses:

POST

Parameters:

Body: NONE

Responses:

File cleaning

/api/rest/filecleaning/deleteorphans

GET

Parameters:

Body: NONE

Responses:

Files gestion config

/api/rest/filesgestionconfig

POST

Parameters: NONE

Body:

Responses:

/api/rest/filesgestionconfig/{id}

POST

Parameters:

Body:

Responses:

/api/rest/filesgestionconfig/{idLibrary}

GET

Parameters:

Body: NONE

Responses:

Ftp configuration

/api/rest/ftpconfiguration

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/ftpconfiguration/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Health

/api/rest/health

GET

Parameters: NONE

Body: NONE

Responses:

Help page

/api/rest/help

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/help/{id}

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Image metadata

/api/rest/imagemetadata

GET

Parameters:

Body: NONE

Responses:

POST

Parameters: NONE

Body:

Responses:

/api/rest/imagemetadata/{id}

POST

Parameters: NONE

Body:

Responses:

Import

/api/rest/import

POST

Parameters:

Body:

Responses:

Import report

/api/rest/importreport

GET

Parameters:

Body: NONE

Responses:

/api/rest/importreport/{id}

GET

Parameters:

Body: NONE

Responses:

DELETE

Parameters:

Body: NONE

Responses:

Imported doc unit

/api/rest/impdocunit/{id}

POST

Parameters: