Page History

...

Camel makes use of "components" to integrate various services using a terse, domain specific language (DSL) that can be expressed in JAVA, XML, Scala or Groovy. There exists one such component an fcrepo-camel component designed to work specifically with a Fedora4 repository. This makes it possible to model Solr indexing in only a few lines of code like so:

XPathBuilder xpath = new XPathBuilder("/rdf:RDF/rdf:Description/rdf:type[@rdf:resource='http://fedora.info/definitions/v4/indexing#Indexable']")
xpath.namespace("rdf", "http://www.w3.org/1999/02/22-rdf-syntax-ns#")

from("activemq:topic:fedora")
  .to("fcrepo:localhost:8080/fedora/rest")
  .filter(xpath)
    .to("fcrepo:localhost:8080/fedora/rest?transform=default")
    .to("http4:localhost:8080/solr/core/update");

...

from("direct:delete")
  .process(new SparqlDescribeProcessor())
  .to("http4:localhost:3030/db/query")
  .process(new SparqlDeleteProcessor())
  .to("http4:localhost:3030/db/update");
 
from("direct:new")
 .to("fcrepo:localhost:8080/rest")
 .process(new SparqlInsertProcessor())
 .to("http4:localhost:3030/db/update");
 
from("direct:update")
  .to("fcrepo:localhost:8080/rest")
  .process(new SparqlUpdateProcessor())
  .to("http4:localhost:3030/db/update");

When using these Sparql* processor classes, it is also possible to apply these operations to named graphs. While Fedora does not support named graphs, it is possible to assign nodes to certain named graphs in an external triplestore. The CamelFcrepoNamedGraph header can be used to apply a sparql-update operation to a particular named graph. For instance, to route all operations to a named graph (in this case the graph URI is defined dynamically as a property placeholder: 

from("direct:update")
  .to("fcrepo:localhost:8080/rest")
  .setHeader(FcrepoHeaders.FCREPO_NAMED_GRAPH)
    .simple("{{named.graph}}")
  .process(new SparqlUpdateProcessor())
  .to("http4:localhost:3030/ds/update"); 

Or, to partition the graph based on an existing RDF property:

from("direct:update")
  .to("fcrepo:localhost:8080/rest")
  .setHeader(FcrepoHeaders.FCREPO_NAMED_GRAPH)
    .xpath("/rdf:RDF/rdf:Description/ex:namedGraph/text()", String.class, ns)
  .process(new SparqlUpdateProcessor())
  .to("http4:localhost:3030/ds/update");

Or, you may want (possibly overlapping) "public" and "private" named graphs, defined as constants:

from("direct:update")
  .to("fcrepo:localhost:8080/rest")
  .multicast("direct:public", "direct:private");

from("direct:public")
  .filter(publicPredicate)
    .setHeader(FcrepoHeaders.FCREPO_NAMED_GRAPH)
      .constant("http://site/graph/public")
    .process(new SparqlUpdateProcessor())
    .to("http4:localhost:3030/ds/update");

from("direct:private")
  .filter(privatePredicate)
    .setHeader(FcrepoHeaders.FCREPO_NAMED_GRAPH)
      .constant("http://site/graph/private")
    .process(new SparqlUpdateProcessor())
    .to("http4:localhost:3030/ds/update");

In each case the Sparql update operation will include a GRAPH <uri> { ... } clause, where uri is the value of the FCREPO_NAMED_GRAPH header (in the Spring DSL, this header can be accessed as CamelFcrepoNamedGraph). It is important that the value of the named graph header is a properly formed URI.

Event-based Routing

It is often helpful to route messages to different queues based on the eventType value. This example splits messages on eventType values and routes the messages to appropriate queues. Following this example, it would be prudent to aggregate the messages based on org.fcrepo.jms.identifier value after retrieving the messages from the downstream queues.

...