• Description
• List of services
• Setup
• Importing Data
  • Data sources
• Frontend
  • Technologies
  • Usage
  • Environment
• Debugging/logging
• More information

Based on the mu-semtech microservice architecture for the backend en Emberjs for the frontend.

git clone https://github.com/lblod/app-worship-harvester.git

cd app-worship-harvester

docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

It takes a minute before everything is up and running. In case there is an error the first time you launch, just stopping and relaunching docker compose should resolve any issues.

Simply visit http://localhost:80 and you will redirected to the yasgui sparql interface. More info about the frontend in the frontend section below.

The frontend is what the user actually interacts with. With the use of our addons you are presented with a sparql interface and when visiting different routes with the corresponding , rdf-friendly, data. It is build on top of the Ember.js framework. And server side rendered by Fastboot

To make sure the app can share data, producers need to be set up. There is an intial sync, that is potentially very expensive, and must be started manually

1. make sure the app is up and running, the migrations have run
2. in docker-compose.override.yml, make sure the following configuration is provided:

  delta-producer-background-jobs-initiator-besluiten:
    environment:
      START_INITIAL_SYNC: 'true'

3. drc up -d delta-producer-background-jobs-initiator-besluiten
4. You can follow the status of the job, through the dashboard

This app allows you to both add authentication fields to the job & scheduled-jobs request as protect the app from unauthorized access via both the frontend app and api. To allow authentication you need to add an environment variable to the frontend-harvester-self-service service and update the mu-auth config.

Add the EMBER_AUTHENTICATION_ENABLED environment variable to the frontend service and set it to TRUE

frontend:
    image: lblod/frontend-harvesting-self-service:1.9.2
    environment:
      EMBER_AUTHENICATION_ENABLED: 'true'
    volumes:
      - ./config/frontend:/config
    labels:
      - "logging=true"
    restart: always
    logging: *default-loggingEMBER_AUTHENICATION_ENABLED: 'true'

Add the following function to the config:

defmodule Acl.UserGroups.Config do
  ...
  defp logged_in_user() do
    %AccessByQuery{
      vars: [],
      query: "PREFIX session: <http://mu.semte.ch/vocabularies/session/>
              SELECT DISTINCT ?account WHERE {
                  <SESSION_ID> session:account ?account.
        }"
      }
  end
  ...

Set the access function of the harvesting group to the logged_in_user() function:

  ...
  def user_groups do
    [
      # Harvesting
      %GroupSpec{
        name: "harvesting",
        useage: [:write, :read_for_write, :read],
        access: logged_in_user(),
        graphs: [ %GraphSpec{
          ...

Note: make sure you are running a frontend-harvesting-self-service version that has the AUTHENTICATION_ENABLED feature flag

At last you will need to remove the DEFAULT_MU_AUTH_ALLOWED_GROUPS_HEADER & DEFAULT_ACCESS_CONTROL_ALLOW_ORIGIN_HEADER variables from the identifier service.

To have access to the frontend app you will need to create an account through migrations.

• The default virtuoso settings might be too weak if you need to ingest the production data. Hence, there is better config, you can take over in your docker-compose.override.yml

  virtuoso:
    volumes:
      - ./data/db:/data
      - ./config/virtuoso/virtuoso-production.ini:/data/virtuoso.ini
      - ./config/virtuoso/:/opt/virtuoso-scripts

Not all required parameters are provided, since deploy specific, see report-generator

Should have credentials provided, see deliver-email-service