Copyright (C) 2016-2018 The Open Library Foundation
This software is distributed under the terms of the Apache License, Version 2.0. See the file "LICENSE" for more information.
FOLIO compatible inventory module.
Provides basic physical item inventory management, currently limited to basic representations of local instances and items, which can only be created via a MODS import.
Written in Java and uses Maven as its build system.
This readme is intended to get these modules up and running. For further information on what they do, see the guide.
- Java 8 JDK
- Maven 3.5.0
- Node 6.4.0 (for API linting and documentation generation)
- NPM 3.10.3 (for API linting and documentation generation)
- Python 3.6.0 (for deployment scripts and tests via okapi setup)
There are some common RAML definitions that are shared between FOLIO projects via Git submodules.
To initialise these please run
git submodule init && git submodule update in the root directory.
If these are not initialised, document generation and API linting operations may fail.
More information is available on the developer site.
Groovy and Gradle
If sdkman is installed, run
source ./setup-environment.sh to setup the shell with the appropriate versions of Gradle and Groovy.
mvn compile from the root directory.
In order to build an executable Jar (e.g. for Okapi to deploy), run
A script for building and running Okapi is provided. Run
/start-okapi.sh from the root of the Okapi source.
As this runs Okapi using Postgres storage, some database preparation is required. This can be achieved by running
./create-okapi-database.sh from the root of this repository.
In order to activate the inventory module for a tenant, the dependencies described in the Module Descriptor need to be fulfilled.
The simplest way to fulfil these is to use the inventory storage module.
To register the module with deployment instructions and activate it for a demo tenant, run
./start-managed-demo.sh from the root directory.
To deactivate and unregister the module, run
./stop-managed-demo.sh from the root directory.
Importing/ingesting of sample data is done via Okapi, so modules must be registered prior to importing.
To load some sample data run
./import-sample-data.sh from the root directory.
These modules provide HTTP based APIs rather than any UI themselves.
As FOLIO is a multi-tenant system, many of the requests made to these modules are tenant aware (via the X-Okapi-Tenant header), which means most requests need to be made via a system which understands these headers (e.g. another module or UI built using Stripes).
Okapi Root Address
It is recommended that the modules are located via Okapi. Access via Okapi requires passing the X-Okapi-Tenant header (see the Okapi guide above for details).
Operating System Support
Most of the development for these modules, thus far, has been performed on OS X, with some on Ubuntu. Feedback for these, and particularly other operating systems is very welcome.
The inventory.all permission set currently represents all of the permissions needed to use the inventory related parts of the system (e.g. the scan application and its configuration). This means that it contains additional permissions than those directly needed by the inventory module itself.
The guide and other documentation for this module.
Other FOLIO Developer documentation is at dev.folio.org
Appendix 1 - Docker Information
When Using the Modules as Docker Containers
For the modules to communicate via Okapi Proxy, when running in Docker containers, the address for Okapi Proxy needs to be routable from inside the container.
This can be achieved by passing a parameter to the script used to start Okapi, as follows
Where 192.168.X.X is a routable IP address for the host from container instances and both repository clones are at the same directory level on your machine.
Finding a Routable Address
Finding the appropriate IP address can be OS and Docker implementation dependent, so this is a very early guide rather than thorough treatment of the topic.
If these methods don't work for you, please do get in touch, so this section can be improved.
ifconfig docker0 | grep 'inet addr:' should give output similar to
inet addr:192.168.X.X Bcast:0.0.0.0 Mask:255.255.0.0, , the first IP address is usually routable from within containers.
On Mac OS X (using Docker Native),
ifconfig en0 | grep 'inet ' should give output similar to
inet 192.168.X.X netmask 0xffffff00 broadcast 192.168.X.X, the first IP address is usually routable from within containers.