Custom Service

Desktop Cloud Developer New Feature

Overview

Custom Service is a new built-in service for script-driven HTTP integrations. It lets a finScript issue an outbound HTTP request to any URL — with any method, headers, query parameters and body — and have the whole call recorded automatically in the standard Service Log, optionally with a linked Client, Account or Account Application Log.

Before this release, a script that needed to call an external system had to build and manage its own HTTP plumbing, and any auditing was up to the developer. Custom Service gives those integrations first-class treatment: a consistent Service Log entry for every request and response, a rendered summary page, and data-retention handling — the same machinery the built-in provider services use — without having to hand-roll it.

It is an entirely business-layer / scripting capability. There is no form or configuration widget: each request carries its own URL and credentials, so it works identically anywhere finScript runs — Desktop, Web Services and Cloud.

This is the outbound Custom Service

Custom Service is about finPOWER Connect calling out to another system. Do not confuse it with the existing "Custom Web Service" mechanism, which is inbound (running your Scripts as web services). They are unrelated.

Prerequisites

No Add-On, licence option or country registration is required — Custom Service is always available

The ability to author and run finScript (this is a scripting feature)

A target endpoint URL, plus any headers / credentials that endpoint requires

Setup & Configuration

Custom Service has no configuration surface — there is no Cost Centre service page and no Cost Centre Edit widget. Each request supplies its own URL, headers and credentials at run time, so there is nothing to set up before using it.

The only optional configuration point is a display override: you can register a Summary Page script (Cost Centre script type Summary Page.CustomService) to change how the resulting Service Log renders. That affects presentation only, not the HTTP behaviour.

Per-request transport options are available on the service where you need them, including proxy settings, a request timeout, a client certificate (format, name, password, and an option to disable certificate validation), and credential caching.

How to Use

Custom Service is reached from a script through finBL.CustomService. There are two adoption patterns.

Full pattern — let the service make the call and log it

Create and populate a request

Call finBL.CustomService.CreateRequest() and set the request's RequestUrl, Method, Payload, ContentType, RequestHeaders and RequestParameters (and an optional EnquiryReference).

Execute

Call finBL.CustomService.Execute(request, response, ...) to make the call and write the Service Log, or ExecuteWithLog(...) to also create a linked Client / Account / Account Application Log (the most specific record wins). The response object gives you the status, body and any failure reason.

Migration pattern — keep your own HTTP call, add the auditing

Create a pending Service Log

Call CreateServiceLog(...) (or CreateServiceLogWithLog(...)) to open a pending Service Log row and get back its key.

Make your call, then close the log

Make the HTTP call however you already do, then call UpdateServiceLog(serviceLogPk, isSuccessful, responseString, responseBytes, failedReason) to flip the pending row to Completed or Failed. The result is an identical Service Log to the full pattern.

To render a stored call, GetHtmlFromServiceLog(...) returns the summary HTML, and CreateResponseFromServiceLog(...) reconstructs a response object from a logged request.

Platform Differences

Custom Service is a business-layer object with no dedicated UI on any platform, so it behaves identically wherever a script calls it — Desktop, Web Services and Cloud (Cloud scripts reach it through Web Services). The rendered Service Log summary (CustomServiceEnquiryReport) is available on both Desktop and Cloud.

Permission Keys

Custom Service has no dedicated permission key. Access is governed by the standard script authoring and execution permissions of whatever scripting host calls finBL.CustomService.

Settings

There are no Global, User, Role or Cost Centre settings for Custom Service — behaviour is entirely per request. Note the built-in Service Log retention behaviour: successful requests are retained, while failed requests are retained for 30 days.

Tips & Best Practices

Tip — Prefer Custom Service over raw HTTP in scripts

Even for a one-off integration, routing the call through Custom Service gives you a consistent, auditable Service Log and a rendered summary for free — a big improvement over ad-hoc HTTP calls that leave no trace. Use ExecuteWithLog when the call belongs to a specific Client, Account or Account Application so it shows up on that record.

Tip — Retro-fit auditing without rewriting

If you already have working HTTP code in a script, the migration pattern (CreateServiceLog → your call → UpdateServiceLog) lets you add the same auditing without changing how the request itself is made.

Important — Mind what you log

Because the request and response are written to the Service Log, be deliberate about sensitive data in headers or bodies. Avoid logging secrets you would not want retained, and use the per-request transport options (such as the credential cache) rather than embedding credentials where they will be recorded.

Knowledge Base References

Browse the live KB listings for v6.00.04 on the Intersoft support site:

Desktop & Business Layer Cloud Web Services

The Knowledge Base article for this feature:

KB 22547

New

Custom Service — script-driven HTTP integrations