Topic: Syspro 8 Connector Gateway API Service

• Windows Event Viewer, Application log, source SYSPROCGS: startup progress, retries, and failure messages, with descriptive text for each stage.

• The CustomHealthLogger log category, for the overall health verdict. Look for the “HEALTHY => Yes” entry described below, or its absence, to determine the service’s own verdict on its state, separate from the Windows service status.

As the service retries indefinitely on most failures, a service that is currently healthy may still display earlier failure or retry entries in the log. These do not necessarily indicate an ongoing problem. Check the most recent entries and confirm whether retries are still occurring now, rather than relying on whether a failure was ever logged.

On a clean startup, entries appear in approximately the following order. Compare the live log against this sequence to determine whether startup is progressing normally or has stalled at a specific stage:

1. Stage 1 completes silently. There is no entry of its own; successful completion is confirmed by the appearance of Stage 2’s entries next. If the Stage 1 warning repeats instead, startup has stalled at this stage.

2. Stage 2, endpoint resolution. Informational entries appear as each cloud address resolves (admin, payment, and tax; tax only if resolving from configuration rather than dynamically), followed by EventId 1000 confirming the whole step succeeded, then EventId 1205 confirming the connector-gateway address specifically. EventId 1205 fires once, not once per endpoint.

3. Stage 2, diagnostic dump. Informational entries appear per endpoint (payment, tax, admin, connector-gateway). This is not itself a pass or fail signal.

4. Stage 3 completes silently (tenant ID, then lock request). There are no entries of their own. A repeating “Failed to get Syspro Tenant ID, retrying” message here indicates that startup is stalled at this point instead.

5. Stage 3, lock acquired. “Request received Acquire Lock” appears. The absence of a following “only one processor allowed” or endpoint-not-set message confirms success.

6. Stage 4 completes silently (credential and API key exchange). There is no entry of its own.

7. Notification bus processor starts. An informational entry confirms that the processor started for this company and topic.

8. Overall health confirmation. EventId 1001, “HEALTHY => Yes”. This can appear slightly before or around the same time as step 7, since it requires most, though not all, of the startup stages to have passed.

9. Running throughout in the background, with no entry either way: the notification bus monitoring loop described in Stage 5 below. Its silence is normal and should not be taken as an indication of a problem.

General guidance: the stage whose retry or warning text is currently repeating is the point at which startup has stalled. Everything listed after it has not yet been attempted. If 'Healthy => Yes' appears but a specific feature (for example, notifications) is still not working, the fault lies downstream of that line, most likely the unlogged Stage 5 background task described below.

Succeeds: No dedicated success entry exists for this step. The absence of the failure warning, together with later stages proceeding, confirms that this step passed.

Fails: A warning entry reports that the connector could not confirm the local Syspro service was healthy (session or logon check failed).

What the log cannot distinguish: the local Syspro 8 e.NET Communications Load Balancer service being down entirely, the server being reachable but timing out, a SOAP or communication fault, and a bad logon or session. All of these produce the same generic warning text; there is no separate message for 'server unreachable' versus 'server reachable but rejected the logon'.

Likely causes, in order:

• The local Syspro 8 e.NET Communications Load Balancer service is not running or is not reachable on its configured host and port.

• A network, firewall, or binding issue between the connector and the local WCF server. This is less common than the first cause, since this traffic is usually confined to the same server or local network.

• The Syspro 8 e.NET Communications Load Balancer service is running, but the connector’s logon or session to it is failing (credentials, session limits). This appears identical in the log to the first two causes, so the server should not be assumed to be down without also confirming that it is accepting logons.

Succeeds: Informational entries confirm that each cloud address was resolved (admin and payment endpoints; the tax endpoint only when the Syspro Application Gateway Service is set up to resolve endpoints from configuration rather than dynamically).

Fails: Error entries report that a specific endpoint (admin, payment, or tax) could not be resolved, along with a separate pair of entries relating to writing the resolved connector-gateway address back and reading it back for confirmation.

The write-back entry indicates the following:

The write-back and read-back confirmation log line carries two separate pieces of state in its text: whether the write succeeded and whether the read-back succeeded. Support can read both values from the same line to distinguish a write failure from a read-back failure, or from a same-value timing mismatch, rather than treating every “write-back failed” entry as a single undifferentiated problem.

A known wording inconsistency:

Two different underlying error conditions have been found to reuse the same message text:

• 'cloud payments api endpoint'

  This occurs even when the endpoint actually being resolved is the admin or connector-gateway endpoint rather than the payment endpoint.

• App Gateway base address

  has also been found on a connector-gateway read-back failure. In both cases, the entry should be read as an endpoint resolution failure, with the specific endpoint confirmed from context (timing, and the stage in progress) rather than from the endpoint name printed in the message text.

• Likely causes, in order:

  • The Syspro Application Gateway Service is not yet configured within Syspro. This is the most common cause on a fresh installation.

  • The Syspro Application Gateway Service configuration exists but has an invalid or incomplete value for the specific endpoint reported as failing.

  • A same-value mismatch or timing lag between what was written and what was read back. The two embedded success and fail values on the write-back entry should be checked before assuming this is a fresh configuration problem.

    Tax eendpoint resolution is skipped entirely when the connector resolves endpoints dynamically rather than from configuration.

    This is confirmed, expected behavior in that mode, not a fault.

Succeeds: Separate informational entries confirm that the tenant ID was retrieved, and that the processing lock was acquired.

Fails: Separate error entries appear shared across several of these calls:

• Could not retrieve tenant ID

• Could not acquire or build the processing lock request

• Error when calling business object (generic warning-style entry)

  During the tenant ID, credential, and API key validation steps, both business object errors and local Syspro 8 e.NET Communications Load Balancer session errors produce the same generic message. The log entry alone may therefore not indicate the underlying cause.

  Connectivity issues with the cloud Admin API generate a distinct exception message. The lock acquisition step is local and is not affected by this behavior.

Likely causes, in order:

• The server cannot reach the cloud Admin API (DNS, firewall, proxy). This usually produces its own distinct error text rather than the generic business-object message.

• A business-object-level error on the local Syspro side while looking up the tenant ID or building the lock or credential request. This appears the same in the log as the third cause, so a cloud problem should not be assumed without also checking the local WCF and business-object side.

• A local Syspro 8 e.NET Communications Load Balancer session-level failure during the same call. This is indistinguishable in the log from the second cause; both should be checked.

• For locking specifically: Another active connector instance already holds the lock for this company. This is expected if two instances are running, or if a previous instance did not shut down cleanly.

Succeeds: An informational entry confirms that the API key and credential exchange completed.

Fails: An error entry appears for the API key exchange, using the same generic “error when calling business object” form as the tenant ID step.

What the log cannot distinguish:

The same ambiguity described in Stage 3 applies here. A business-object error and a local Syspro 8 e.NET Communications Load Balancer session error appear identical in this entry.

Likely causes (the same as stage 3):

• A local business-object or Syspro 8 e.NET Communications Load Balancersession problem on this specific call.

  A reachability problem to the Admin API is less likely at this stage, since Stage 3 would typically have failed first.

Overall startup success signal:

Once the tenant ID, lock, and credential and API key exchange all succeed, a distinct informational entry is logged confirming that initialization completed, with an explicit 'Healthy => Yes' statement. This single line confirms that stages 1 through 4 have passed, separate from the individual per-step entries.

Succeeds: An informational entry confirms that the notification bus processor started successfully for this company and topic.

Fails (setup path: topic or subscription creation, connection string): A generic error entry ('an error occurred in the processor task') that repeats on a retry cycle, commonly at intervals of around 10 seconds, until it succeeds.

Fails silently (a known gap which should be escalated to engineering rather than treated as a missing log entry): The background task that periodically checks whether processors should be started or stopped runs on its own loop, with no logging and no error handling at all. If a fault occurs at this level, as distinct from within the processor startup itself, no corresponding SYSPROCGS entry exists. The resulting symptom is that notifications silently stop being picked up, with nothing in the log indicating why. If stages 1 through 4 all show as healthy and notifications are still not flowing, and there is no repeating error entry for the processor task, this gap should be suspected rather than continuing to search the log for an entry that may not exist.

Likely causes, in order:

• Outbound connectivity to Azure Service Bus is blocked (firewall or proxy). This usually appears as the repeating 'error occurred in the processor task' entry.

• The lock, topic, or subscription setup for this company is failing (credentials from stage 4 not yet valid, or another instance holding the lock). This produces the same repeating entry.

• No log entry at all, despite a genuine problem: the unlogged background monitoring gap described above. stages 1 through 4 should be confirmed as genuinely healthy first, and 'no entries, but notifications are not arriving' should then be treated as its own case rather than assumed to be normal.

The service typically continues to show as Running in Windows Services even when it has not completed startup.

A Started status is not equivalent to a healthy status. The service logs its own overall health status under the CustomHealthLogger log category; the 'Healthy => Yes' entry described under stage 4 above, or its absence, indicates the service’s own verdict on its state, separate from the Windows service status.