Overview

The Solution Builder provides a set of generic mechanisms that allow you to implement business logic without writing code. However, in many cases the required logic is complex and cannot be implemented using standard Solution Builder means.
In such scenarios, the recommended and universal approach is to implement a custom Web Service and register it in the Solution Builder Web Service Repository.

Goal

Introduce a custom Web Service that is registered in the Solution Builder Web Service Repository and ready to be used in standard Solution Builder scenarios.

Step 1: Implement Web Service Controller

Starting with version 26.1, custom Web Services are defined as .NET types implemented in .NET Standard or .NET assemblies.

The definition of Web Services and Web Methods follows the same semantics and conventions as MVC Web API–based services. However, instead of using the traditional System.Web.Http APIs, the implementation must be based on Matrix42 artifacts provided by the Matrix42.WebApi.Contracts assembly.

Unlike versions prior to 26.1, custom Web Services are no longer hosted inside the M42Service web application and are not managed by MVC Web API. Instead, they are executed in isolated, sandboxed processes managed by the Matrix42 Functional Worker.

Using Data Layer API in Service

In case you want use Data Layer directly in your custom Web Service, you need to add a reference to ..\svc\bin\update4u.SPS.DataLayer.dll assembly to your Project. 


using Matrix42.WebApi.Contracts;

namespace Imagoverum.FleetManagement.Services
{
	[RoutePrefix("api/car")]
	public class CarController : ApiController
	{
		[HttpGet, Route("geoposition")]
		public GeoLocation GetLocation(string region = "world")
		{
			return GeoLocation.GetRandom(region);
		}

		[HttpPost, Route("test")]
		public string TestPost()
		{
			return "string";
		}
	}
}

Step 2: Deploy new Web Service 

Copy the generated assembly (and any dependent assemblies) containing the custom Web Service implementation to:

<ApplicationFolder>\InstalledPackages\Assemblies\{packageId}

Where {packageId} is the ID of the extension for which the Web Service is being developed.
If the extension does not yet exist, create a new Configuration Project, export it as a package, and obtain the {packageId} from the package.json file. Also you can find the right folder in Configuration Project dialog, tabulator “Files”

When packaging the service as a Sandboxed Extension, place the assemblies in the ..\Assemblies folder inside the extension package. Upon installation, they will be deployed automatically to the corresponding extension directory under InstalledPackages.

 

Step 3: Register Custom Assemblies

Starting with version 26.1, custom assemblies are no longer deployed to the application bin folders. Instead, they are stored under: ..\InstalledPackages\Assemblies\{packageID}


To allow the system to locate and load these assemblies at runtime, Solution Builder maintains metadata in the database table DWPExtensionAssemblyClass. This table contains information about:

  • Assembly location
  • Origin
  • Supported runtimes
  • Dependencies

During extension installation, this metadata is detected and stored automatically. In development environments, however, the assembly information must be added to this table manually.

INSERT INTO DWPExtensionAssemblyClass (PackageId, PackageName, PackageVersion, [Name], [Version], RuntimeCapabilities)
VALUES ('{packageID}', '{package.name}', '{package.version}', '{dll.name}', '{dll.version}', 0);

 

Step 4: Synchronize Web Service

 To make it available, you must synchronize the Web Service so that the metadata for the new Web Service is registered.

  1. Open the Solution Builder application.
  2. On the Administration home page, start recording customization changes.
  3. Navigate to Administration → Integration → Web Services.
  4. If Web Service not registered yet, create a new with action “Add WebAPI Service
  5. Select the created Web Service object and execute the Synchronize Server action.

After synchronization:

  • The new Web Service is added to the Service Repository.
  • The Service Layer automatically creates the required endpoints.
  • The service becomes available for use in Solution Builder scenarios.

 

Step 5: Setup permissions

By default, all newly synchronized Web Services and their operations are granted access only to Administrators.

Use the standard Set Audience action to configure the permissions for users or roles that are allowed to execute the Web Service operations.
For details, see Set Audience.

 

Legacy Custom Web Service Implementation

Before version 26.1, custom Web Services were deployed directly to the Matrix42 application folder and hosted inside the M42Service web application. Both declaration and implementation were fully based on MVC Web API.

Key characteristics of the legacy approach:

  • The Web Service class name must end with the suffix Controller; otherwise, the Service Layer will not detect it.
  • The class must inherit from System.Web.Http.ApiController.
  • The project must reference System.Web.Http with the exact version used by the target Application Server.
    To avoid version mismatches, reference the assembly directly from: ..\svc\bin\System.Web.Http


Deployment steps:

  1. Copy the assembly (and dependencies) containing the Web API controller to the bin folder of the web application that will host the service.
  2. If the service is hosted together with Solution Builder (Service Management), copy the assemblies to: svc\bin

Although IIS automatically detects the new Web Service, endpoints are not created automatically for security reasons. Attempting to call the service at this point results in a “The resource not found” error.

To finalize the setup, run the Synchronize Server action as described above.