Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
languagejs
themeRDark
titleoverride.conf
shrine {
  queryEntryPoint{
    audit {
      database {
        dataSourceFrom = "testDataSource" //Can be JNDI or testDataSource . Use testDataSource for tests and command line tools, JNDI everywhere else
        testDataSource {
          driverClassName = "com.mysql.cj.jdbc.Driver" //JDBC driver class name
          url = "jdbc:mysql://localhost:3306/qepAuditDB?serverTimezone=UTC" //URL to your database
          credentials {
            username = "yourUserName"
            password = "yourDatabasePassword"
          }
       }
     }
  }
}


Next, create a file named network.conf to meet your needs. At a minimum include the network section and a section for the hub's QEP:

Code Block
languagejs
themeRDark
titlenetwork.conf
shrine {
  network {
    network {
      name = "Network Name"
      hubQueueName = "hub"
      adminEmail = "yourEmail@yourhospital.edu"
      momId = "HubQueue"
    }
    nodes = [
      {
        name = "Hub's QEP"
        key = "hub-qep"
        userDomainName = "network-hub"
        queueName = "shrinehub"
        sendQueries = "false"
        adminEmail = "yourEmail@yourhospital.edu"
        momId = "HubQepQueue"
      }
    ]
  }
}

...

For most shrine networks we recommend using shrine's in-tomcat messaging system: Networks that want to minimize administration effort, small networks, isolated networks, networks set up for demonstrations, and networks with few researchers. The main drawback to shrine's in-tomcat messaging is that messages in-flight and in-process are stored in memory; if a message is in transit when the hub admin stops tomcat it will be lost. (The 45-node ACT network has used this messaging system since SHRINE 1.25 with few incidents.)

There 's is no additional configuration or set-up to use this messaging system.

...

To configure for AWS SQS see SHRINE 4.1.0 Chapter 8.2.1 - Configuring a Hub for AWS SQS .

Kafka

We currently do not recommend Kafka for known SHRINE use cases. Kafka requires much Shrine can also be configured to use Kafka. Using Kafka requires setting up, securing, and maintaining a cluster of Kafka servers - more admin expertise, attention, and expense than AWS SQS with fewer without the benefits of AWS SQS' reliability. The SHRINE development team supports it internally to expose some performance bugs we hope to fix in the next release. 

To configure for Kafka see SHRINE 4.1.0 Chapter 8.2.2 - Configuring a Hub for Kafka .

...