Installing the Session-enabled Content Service
The Session-enabled Content Service is the alternative for the regular Content Service, to be used in a Content Delivery environment that enables inline editing of its content using the Experience Manager user interface. When the Session-enabled Content Service is installed, the Content Service does not need to be installed.
- Copying resources for the Session-enabled Content Service
Copy the microservice resources, or copy the contents of a WAR file to a Web application location. - Setting a log location for your microservice
By default, Content Delivery microservices write their log files to a folder called c:/SDLWeb/log/. Set a proper location in the Logback configuration file for your microservice, logback.xml. - Configuring Content Data Store database access for your microservice
Your microservice uses the Storage Layer to access the Content Data Store, where all content is stored. To configure content storage in one or more databases, addStorageelements to the file. - Configuring session data storage for the Session-enabled Content Service
Configure Experience Manager to store session data in a dedicated database by editing the Storage Layer configuration files, cd_storage_conf.xml, used by the Session-enabled Content Service. If you have two or more staging environments, you can also configure load balancing. - Configuring the Ambient Data Framework for the Session-enabled Content Service
Configure Claim forwarding, Cartridges and cookies by editing the Ambient Data Framework configuration file, cd_ambient_conf.xml. - Installing a license for your Content Delivery Role
Your Role will not function without a valid license file. - Installing the Session-enabled Content Service as a microservice
Run the appropriate microservice installation PowerShell or Unix script to install and run the standalone microservice. - Securing the microservice with SSL
You may wish to secure your microservice using Secure Socket Layer (SSL), so that an HTTPS connection is required to interact with the service. If you do, you require a certificate signed and issued by a Certificate Authority (CA), a private key, and a keystore containing both of these. You then configure the keystore in the application.properties file of your microservice. You can reuse the same certificate, key and keystore for multiple microservices, so long as they are all running on the same machine. This section assumes that you have no certificate, key or keystore yet. If you do, you can skip the topics that do not apply. - Connecting to an HTTPS-secured Discovery Service
If you secured your Discovery Service with HTTPS, you imported your certificate into a keystore which you passed to the Discovery Service. To connect to the Discovery Service, import the same certificate into your local Java keystore. - Registering the Session-enabled Content Service as a Capability
If you already used theauto-registerswitch to register this Server Role as a Capability when you installed it as a standalone microservice, you can skip this task. If you did not, you can make this microservice discoverable through the Discovery Endpoint by hand by adding it as a Capability to the Discovery Service's Storage Layer configuration file and update the Capability registry by rerunning the Discovery Service registration tool. Note that the service registers itself as a Content Service.
Related tasks