Develop and Register Web Service
Implementing a custom Web Service and registering it in the SolutionBuilder Web Service Repository.
Table of Contents
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.
- Open the Solution Builder application.
- On the Administration home page, start recording customization changes.
- Navigate to Administration → Integration → Web Services.
- If Web Service not registered yet, create a new with action “
Add WebAPI Service” - Select the created Web Service object and execute the
Synchronize Serveraction.
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.Httpwith 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:
- Copy the assembly (and dependencies) containing the Web API controller to the bin folder of the web application that will host the service.
- 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.