Configuring Windows Communication Foundation

This page describes the installation and configuration process of Windows Communication Foundation (WCF). You need to configure WCF to use the following Xperience features:

WCF overview

WCF is a component of the .NET Framework that provides a programming model for building service-oriented multi-platform applications that communicate across the web. For more information about the technology, visit the What Is Windows Communication Foundation page in the Microsoft documentation.

Installing WCF

WCF is automatically installed with .NET 3.0 and any higher version. However, you still need to install the WCF HTTP Activation feature yourself.

When hosting the Xperience administration on Microsoft Azure Web Apps, WCF and the HTTP Activation feature are installed and enabled by default.

Go to Control Panel -> Programs and Features in Windows and click Turn Windows features on or off in the left menu.

Windows 8.1 / Windows Server 2012

  1. Expand the .NET Framework 4.5 Advanced Services item.
  2. Make sure that the WCF Services -> HTTP Activation feature is installed.

Windows 10 or 11

  1. Expand the .NET Framework 4.8 Advanced Services item.
  2. Make sure that the WCF Services -> HTTP Activation feature is installed.

Windows Server 2016 / 2019

  1. In the Add Roles and Features Wizard, click Next until you get to the Features step.
  2. Expand the .NET Framework 4.7 Features item.
  3. Make sure that the WCF Services -> HTTP Activation feature is enabled.
  4. Click Next until the Install button is enabled.
  5. Click Install and continue with the wizard.

The system installs WCF on your computer.

After installing WCF on a machine that already had ASP.NET installed, you may need to re-register ASP.NET into IIS.

Configuring WCF services to use HTTPS

WCF services in the Xperience administration application are defined as service endpoints. Based on whether your administration application uses a secured (HTTPS) connection, the service endpoints point to either HTTP or HTTPS bindings.

Service endpoints and bindings are defined in local, application-specific, web.config files. By default, the web.config files contain a public HTTP endpoint, but the system automatically registers a secured endpoint when running over HTTPS.

If you have an advanced environment configuration, and wish to set up your own secured endpoints, you can disable the automatic behavior (separately for the advanced workflow and marketing automation service):

  1. Disable the automatic registration of the secured endpoint to avoid conflicts, by adding one or both of the following keys to the appSettings section of the administration project’s main (root) web.config file:

    
    
    
     <add key="CMSDisableGeneratedAutomationSecureEndpoint" value="true" />
     <add key="CMSDisableGeneratedWorkflowSecureEndpoint" value="true" />
    
    
     
  2. Locate the application-specific web.config files according to the following table:

    Application

    Web.config location

    Marketing automation

    /CMSModules/Automation

    Workflow

    /CMSModules/Workflows

  3. Edit the application-specific web.config file.

  4. Uncomment the secured endpoint code and adjust it as required. The endpoint is defined in the configuration/system.serviceModel/services section.

    Example - commented HTTPS (secure) endpoint for Workflow
    
    
    
      <!--<endpoint name="Secure" address="" behaviorConfiguration="WorkflowDesignerEndpointBehavior" binding="webHttpBinding" bindingConfiguration="WorkflowDesignerSecureBinding" contract="CMS.WebServices.IWorkflowDesignerService" />-->
    
    
     
  5. Comment out (or delete) the non-secured endpoint code.

    Example - HTTP (non-secure) endpoint for Workflow
    
    
    
     <endpoint name="Public" address="" behaviorConfiguration="AutomationDesignerEndpointBehavior" binding="webHttpBinding" contract="CMS.WebServices.IWorkflowDesignerService" />
    
    
     

The system now communicates with the services defined in the services section using the specified endpoints.

Developing custom WCF services

If implementing custom WCF services within the Xperience administration project, you need to manually initialize the Xperience application before calling the Xperience API within the service code.

Otherwise you may encounter errors if the first request that starts the application is destined for the WCF service. The standard initialization does not occur, because WCF requests are not processed by the ASP.NET HTTP runtime. For more information, see the WCF Services and ASP.NET article.

You can initialize the Xperience application by calling the CMS.DataEngine.CMSApplication.Init method, for example within the constructor of your WCF service class. See Using the Xperience API externally to learn more.