3. Bug Fixed

Remove Mandatory Matching Validation for Database Upsert

In Agent 3.06.08, Database Upsert operations were required to include either a WHERE clause or an External ID mapping. If neither was configured, the Agent stopped the process and displayed an error. For Agent 3.06.09, this validation has been rolled back to restore the previous behavior. Database Upsert operations are now allowed to continue even when a WHERE clause or External ID mapping is not configured. This change restores compatibility for existing interfaces that rely on the database adapter or existing integration logic to determine how records are matched. Existing Database Upsert interfaces that do not define a WHERE clause or External ID can run again in Agent 3.06.09 without receiving the validation error introduced in the previous version. Interfaces that already use a WHERE clause or External ID mapping continue to work as before.

Fixed Agent Local Web App sidebar and connection UI

In the Agent Local Web App, the sidebar did not always highlight the correct active page when a submenu item was selected. In collapsed mode, tooltips could also remain visible or behave incorrectly after opening a submenu. The sidebar collapsed/expanded state was not remembered after page reloads, and the connection action buttons could wrap unevenly depending on screen size.

Fixed the sidebar active-state logic so the active child menu is highlighted when visible, and the parent menu is highlighted only when the child item is hidden. Tooltip handling was updated for collapsed sidebar mode, and the sidebar state is now remembered using browser local storage. The connection action buttons were also changed to a fixed three-column layout.

This makes navigation and connection actions in the Agent Local Web App more consistent and easier to use.

Prevent Unnecessary Pub/Sub Restart after Subscribe Retry Errors

When the Pub/Sub subscription stream received an error and retries were exhausted, the Agent could stop the active subscriber, mark the connection as disconnected, and trigger a full Pub/Sub restart. This behavior was too aggressive for temporary Pub/Sub errors, such as network instability, invalid replay ID, or Salesforce service-unavailable responses. It could cause unnecessary Pub/Sub interruption even though the subscriber could continue by scheduling another fetch retry. Pub/Sub error handling has been improved so exhausted retries no longer terminate or restart the subscriber. Instead, the Agent keeps the subscriber lifecycle active and schedules the next fetch retry using the correct retry strategy. Depending on the error, the Agent can retry with the stored replay ID, the latest replay, the earliest replay for an invalid replay ID, or a service-unavailable retry delay. This makes Pub/Sub subscription more stable during temporary connection issues or Salesforce Pub/Sub service errors.

Prevent Unnecessary Pub/Sub Restart after Subscribe Retry Errors

Show correct Last Run and Next Run for Agent schedulers

The Salesforce Interface tab reads scheduler runtime information from InterfaceControlRuntime__c. Previously, when the Agent owned the scheduler execution, these per-interface runtime records were not always updated. This affected inbound schedulers and outbound schedulers running through Non-Open firewall Agent execution.

As a result, the interface could run successfully, but Salesforce could still show missing or outdated Last Run and Next Run values.

The Agent now updates the Salesforce InterfaceControlRuntime__c record for each interface covered by an Agent Scheduler. It saves the correct runtime record for V3 Inbound Execution or V3 Outbound Execution.

This makes the Interface tab show accurate Last Run and Next Run information for Agent-managed scheduler executions.

Fix Incorrect Log File Timestamps on Linux

We fixed an issue in the Browse Log where the Created Date for log files could be incorrect on Linux systems.

Some Linux file systems, including ext4, may not provide a reliable file creation timestamp through the standard Java file properties. As a result, the Browse Log file could display the last modification date as the file creation date inside Agent Control Board.

The Agent now reads Linux file timestamps directly from the operating system to display more accurate values:

Created Date — the file’s original creation time
Last Modified Date — the most recent time the file was changed

If the Linux timestamp command is unavailable or cannot read the file information, the Agent automatically uses its existing fallback method. This ensures the Log Browser continues to work on Linux and other operating systems.

This improvement helps users identify the correct log file and understand when it was created and last updated.

Show Clearer Salesforce Login Errors

The issue happened during Salesforce OAuth login. Before the fix, if the Agent could not get a valid Salesforce access token, it could return null instead of reporting the real login problem. This could happen when Salesforce returned an HTTP error status, no response, a request/network error, or HTTP 200 without an access token.

Because the login result was null, later processing could fail with unclear errors, making it hard to know that the real problem was Salesforce authentication.

Now the Agent validates the OAuth response and stops immediately with a clear error message when login fails. It reports the real reason, such as bad HTTP status, no response, request error, or missing access token.

Suppress Empty Values in Outbound XML and JSON Payloads

When No_Export_NULL_value__c was enabled, the Agent suppressed fields with null values, but empty string values could still be included in outbound XML or JSON payloads.

For example, the payload could still contain empty fields like:

or "FieldName": ""

This did not fully follow the “Do not export null value” setting in the interface configuration and could send unnecessary empty fields to the target system.

We have fixed it. The Agent now suppresses both null and empty string values when No_Export_NULL_value__c is enabled for outbound XML and JSON payload generation.

This makes outbound payloads cleaner and ensures the generated payload follows the configured “do not export null value” behavior more correctly.

Fixed Pub/Sub Recovery after Connection Interruption

After a temporary Pub/Sub connection issue, the subscriber channel could recover, but the publisher connection could remain in an old reconnect/backoff state. Because of this, the next publish action might fail before the publisher recovers.

Also, a scheduled subscribe retry could continue waiting even after the channel was already ready again.

This issue has been resolved. The Agent now refreshes the Pub/Sub publisher connection as soon as the subscriber channel becomes ready again. If a subscribe retry is still waiting, the Agent cancels the delay and reconnects immediately.

This makes Pub/Sub recovery faster and reduces unnecessary publish failures after temporary connection issues.

Stop Unexpected Pub/Sub Restart When Saving Configuration

This issue happened when a user saved configuration for an active Non-Open Firewall connection; the agent automatically restarted the Pub/Sub subscriber during the save process. This could cause the connection to temporarily disconnect/reconnect, slow down the save action, or interrupt live event listening, even though the user only wanted to save configuration.

This issue has been resolved by ensuring the saving process no longer restarts Pub/Sub automatically. After configuration is saved, the agent only keeps/updates the connection status as Active, so the existing Pub/Sub connection is not interrupted unexpectedly.

Fix Duplicate Pub/Sub Subscription and Stale Connection Status

When users opened multiple browser tabs or triggered Pub/Sub actions at the same time, the Agent could process concurrent activate, restart, subscribe, or switch requests for the same Salesforce instance URL. In some cases, more than one request could pass the “not active yet” check and create duplicate Pub/Sub subscriptions.

The connection health UI could also become stale. For example, a connection could remain showing Reconnecting even after the underlying Pub/Sub channel was already healthy, or deleted/switched connections might not update correctly in other open tabs.

Added per-instance URL locking for Pub/Sub activate, restart, subscribe, and switch actions. This prevents concurrent requests from creating duplicate subscriptions for the same Salesforce instance.

Connection health handling was also improved so the UI updates more accurately across open tabs. The Agent now broadcasts connection updates when a connection is switched or deleted, and it keeps the displayed connection state synchronized with the real Pub/Sub status.

Fix Wrong InterfaceControlRuntime Update When Multiple Connections Run Concurrently

Fixed an issue where a customer could receive a scheduler alert even though the scheduler was actually running.

This happened when one Integration had multiple Agent Connections, and each connection had its own scheduler. If two scheduler jobs ran at the same time for the same Integration but different connections, the Agent could send the wrong Salesforce REST request while updating InterfaceControlRuntime__c.

The root cause was that Salesforce auth and endpoint URL were stored in a shared field value. Because this service is a Spring singleton, two scheduler jobs running concurrently could overwrite each other’s endpoint/auth values before the request was sent.

As a result, InterfaceControlRuntime__c could be updated incorrectly, especially the LastRun__c or NextRun__c value. Then Skyvva alert logic could detect that the scheduler did not run correctly and send an alert, even though the scheduler job was running.

The fix now creates Salesforce auth and endpoint values per request instead of using shared field values. This prevents one connection/job from overwriting another job’s Salesforce request data when multiple schedulers run at the same time.

Fix CSV Header Matching When File Contains Hidden BOM Character

Fixed an issue when the Agent processes CSV files that contain a hidden character at the beginning of the first column header.

This usually happens when a CSV file is saved from Excel or another tool using UTF-8 with BOM. The column name looks correct in the file, but the Agent reads the first column name differently because of the hidden character.

Because of this, the Agent could not match the first CSV column with the configured mapping field. For example, a field such as Customer ID could look correct in the CSV file, but the Agent could not find it during processing.

This could cause the mapped field value, including External ID fields, to be missing during processing.

The Agent now removes this hidden character automatically, so CSV headers can be matched correctly with the configured mappings.

Fix Wrong Connection Used When Same Salesforce URL Exists

When users had multiple Agent Connections pointing to the same Salesforce org URL, the agent could select the wrong connection during outbound processing in non-open firewall mode. As a result, outbound processing could run with the wrong login, access token, or connection configuration.

This was confusing because the user could ping or manually process using the correct Agent Connection, but the outbound processing could still fail by using another connection from the same Salesforce URL. If that other connection had an invalid login or expired token, the outbound processing could fail without clearly showing that the wrong connection was used.

This issue has been resolved. The agent now uses the specific Agent Connection ID (agentSettingId) to find the correct login details instead of using only the Salesforce URL. This ensures outbound processing uses the same connection configuration selected by the user inside the Agent xxxx Adapter configuration.

Prevent Unsafe Database Delete When Delete Condition Is Missing

Before, when users configured a Database Delete interface, the agent expected a valid delete condition, such as a WHERE condition or External ID mapping, to identify which database records should be deleted.

If this condition was missing or configured incorrectly, the agent could build a delete query that was too broad. This created a risk that the delete process could remove more database records than the user intended.

This issue has been resolved. The agent now checks the delete condition more safely. When no valid delete condition is found, the agent does not perform a broad delete. Instead, it applies a safe no-match condition, so no unintended records are deleted.

This protects business data from accidental deletion caused by incomplete or incorrect Database Delete interface configuration.

Preserve Agent Instance ID When Saving an Agent Connection

Fixed an issue where the Agent Instance ID was saved correctly when an Agent connection was created in open firewall mode, but became empty after the connection was saved again.

When the ID was lost, the Agent Control Board grouped the connection under Unknown, and Agent events could no longer be matched reliably with the correct Agent instance.

The fix updates the connection save flow to preserve and send the existing Agent Instance ID. The Agent now reads the correct Salesforce event field, validates the ID against the running Agent, and keeps the Salesforce Agent Property synchronized.

Users can now create and update Agent connections without losing the Agent Instance ID. Connections remain associated with the correct Agent instance after repeated saves.

Prevent Connection Health Serialization Crash

Before, when the agent returned Connection Health information, the system could fail while converting the data into JSON.

This happened because Agent Setting and Connection Health referenced each other. The JSON conversion kept reading from Agent Setting to Connection Health, then back from Connection Health to Agent Setting again. This repeated until the system hit a StackOverflowError.

When this issue happened, users could not get the connection health response normally. The connection page or health API could fail instead of showing the current connection status.

This issue has been resolved. The agent now skips the repeated back-reference during JSON conversion. Connection Health data can now be returned normally without crashing.

Users can now view connection health information more reliably, including connection status and related health details.

Show Real Failure Reason for Manual Jobs and Improve Log File Names

Before, when a manual job failed, users often saw only a generic message such as “Process is Failed”. This did not explain why the job failed, so users had to check log files to understand the root cause.

After this enhancement, the agent captures the real failure reason and adds it to the job status comment. Users can now see clearer failure information directly from the job result.

Log file names were also improved. The agent now includes the Salesforce org/domain in integration, interface, and Pub/Sub log filenames. This makes logs easier to identify when one agent is connected to multiple Salesforce orgs.

Fix File Consumer Start/Stop Control

Previously, users could have issues when using Start Consumer or Stop Consumer for file-based integrations. Some file consumer routes created during agent startup used a different route ID from the one used by the Start/Stop action.

Because of this, Stop Consumer could appear successful, but the file route might still be running. Also, Start Consumer could create a duplicate route for the same file location, causing the same folder to be watched more than once.

This issue has been resolved. File consumer routes now use a consistent route ID, so Start Consumer and Stop Consumer reliably control the correct route.

Report File Post-Processing Warnings

Previously, errors that occurred while renaming, moving(Backup), or deleting a file could be logged by Camel but not shown in the Job Comment. If the integration data had already been delivered successfully but the final file operation failed, the job could still remain in Completed status without displaying a warning.

This behavior has now been improved. A warning is displayed in the Job Comment when the final file operation fails.

The warning indicates that the file may be:

Open in another application.
Locked by another process.
Located in a folder with insufficient permissions.
Unable to be moved because the destination folder is unavailable or inaccessible.

This behavior applies to local file processing as well as FTP, SFTP, and FTPS connections.

Prevent Salesforce File Transfer Failure When Service URL Is Missing

Fixed an intermittent issue that could prevent a file integration from sending data to Salesforce. The Salesforce session was available, but the Agent could fail while preparing the connection because the Salesforce service URL (svrURL) was temporarily empty. The error log showed:

Cannot invoke "String.indexOf(String)" because "svrURL" is null at com.iservice.sforce.SFService.setupConnectionService(SFService.java:349)

This occurred when multiple operations accessed the shared Salesforce connection while it was still being initialized. One operation could read the connection before the service URL and other required settings were ready.

The Agent now builds the complete Salesforce connector configuration before making it available to other operations. This ensures that the service URL and all required connection settings are initialized before file data is sent. Sending Data from File to Salesforce integrations now work more reliably when multiple jobs run at the same time. This prevents connection failures caused by incomplete Salesforce configuration and allows data transfer to continue when a valid Salesforce session is available.

Fixed SQL Server Query Compatibility

The Agent now provides improved support for valid SQL Server queries that use special column names, declared variables, set operations, and common table expressions.

Escaped column names

SQL Server allows a closing bracket to be used inside a column name by writing two closing brackets:

SELECT [Close]]Reason]
FROM Account;

The Agent now recognizes and preserves this syntax correctly while preparing the query for processing.

DECLARE variables

The Agent now supports a variable declaration followed by a query:

DECLARE @AccountId INT = 1;
SELECT *
FROM Account
WHERE AccountId = @AccountId;

The declared value is resolved before the query is processed.

Combined Queries

SQL Server can combine multiple queries with UNION, INTERSECT, or EXCEPT. The Agent now counts records from every part of the combined query. This prevents incorrect total counts when a query contains more than one result set.

WITH Queries

SQL Server can use a WITH statement to create a temporary result for the main query:

WITH Recent AS (
    SELECT AccountId, Name
    FROM Account
)
SELECT * FROM Recent;

When the Agent creates a count query for pagination, it now keeps the complete WITH section. This allows the generated count query to continue using Recent correctly.

Upgrade Log4j Version for Security

Upgraded Log4j from version 2.26.0 to 2.26.1 in the New Agent to address known security vulnerabilities and improve system security.