3. Bug Fixed

Prevent errors when closing Edit Interface during loading

Closing the Edit Interface while its fields were loading could show a technical error. The loading indicator could also disappear before all fields were ready. The loading spinner now remains visible until the form and lookup fields have finished loading. Responses arriving after the window has closed no longer try to update that closed window. Users can open and close the interface editor without the reported loading error and can more clearly see when the form is ready.

Update the overall message status after all records are complete

An API message and its response could remain Partial Completed even after all related business messages had completed successfully. For example, all Account records could show Completed, while their overall API message still showed Partial Completed. Now we have fixed this by having SKYVVA recalculate the overall status from the related messages after processing or reprocessing. So when all related messages are completed, the overall message updates to Completed. If records still need attention, the overall status continues to reflect that.

Show the correct Data Type options for older inbound interfaces

In Data Loader, an older interface without an API version or Message Type could show XML and JSON under Data Type, although that interface should use CSV.

Now we have fixed this so that the available Data Type options follow the interface configuration:

• V2 inbound interfaces, including older interfaces with no Interface API version and no Message Type: CSV.
  
• Other supported interface configurations: CSV, XML, and JSON.

Now Users are guided to the appropriate file format instead of being offered unsuitable options for an older interface.

Record errors when a scheduler cannot schedule its next run

If a global scheduler such as Checker failed to schedule its next run, SKYVVA could fail to save the error in the log. Administrators had little information to explain why scheduled activity stopped.

We have resolved this by having the scheduling error handler now prepare the logging context needed to save these failures, including the job and error details. So administrators have an error record to investigate when scheduling fails. This change improves error reporting; it does not automatically resolve every cause of a scheduler failure.

Prevent outbound response processing from failing because its tracking reference is too long

After processing incoming data, SKYVVA can prepare an asynchronous response to send back to the external system through a linked response outbound interface.

When this response used CDC Change Pointer processing, creating its tracking record could fail. The tracking reference contained 55 characters, but its field allowed only 36 characters. This prevented the response from being queued through this process.

We have fixed this by updating the External ID field to support 55 characters. The tracking reference also includes the originating message ID, helping SKYVVA distinguish separate requests for the same business record. SKYVVA can save the complete tracking reference and queue the asynchronous response without the reported field-length error. For example, an external system sends an Account to SKYVVA. After processing it, SKYVVA can create the tracking record needed to send the response back through the configured response interface.

Improve outbound reprocessing with Queueable Apex

This enhancement applies when the outbound interface uses Outbound Processing Behavior \= QUEUEABLE, and users reprocess messages after the interface has run. When users clicked Reprocess, SKYVVA could create separate Queueable Apex jobs for parent and child business records. For example, an Account with two related Contacts could create three jobs: one for the Account and one for each Contact.

Now, SKYVVA starts reprocessing from the eligible parent business message. Its related child messages are handled within the parent’s processing flow, without creating independent child jobs. An Account and its related Contacts are reprocessed together through the Account’s Queueable Apex job. This reduces separate processing jobs and keeps related records together.

Show clear guidance when the Agent does not support Test Connection on Adapter

When users clicked Test Connection with an older Agent version, the screen could display the error “Unknown action: Test Connection.” The Agent did not support the Test Connection function, but the message did not explain that an upgrade was required.

SKYVVA now checks the reported Agent version before sending the test request. If the version is below 3.06.10, it explains that Test Connection is unsupported and directs users to check the Agent release notes and upgrade. For Non-Opening Firewall connections, users must enter the correct Agent Version in the Agent Connection settings.

Customers receive clear upgrade guidance instead of an unclear “Unknown action” error. After upgrading to a compatible Agent and updating the connection settings, they can run Test Connection again.

Prevent duplicate OAuth token settings when outbound requests run together

When multiple outbound requests used the same adapter, they could try to save authentication tokens at the same time. If no token record existed, several requests could each create one, resulting in duplicate token settings. When an existing token expired, requests could fail with “UNABLE_TO_LOCK_ROW”, meaning another request was already updating the same record.

Now SKYVVA has been fixed by temporarily locks the adapter record before checking and saving its token settings. This allows one request at a time to perform the update.

For example, if eight requests try to save a token for an adapter that has none, the first request creates the token record. Subsequent requests find and update that record instead of creating additional records. This change controls how tokens are saved; it does not make all requests share a single token-refresh operation.

Apply the interface’s SOQL query before creating polling messages for Agent adapters

When an outbound interface used an Agent adapter in Polling mode and was executed through invokeCalloutV3, SKYVVA could create messages for the supplied record IDs without applying the interface’s SOQL query (skyvvasolutions__Query__c). Records that did not match the query conditions or exceeded its record limit could therefore be included.

This issue has been resolved. SKYVVA now checks the supplied record IDs against the interface’s SOQL query before creating polling messages. It applies both the WHERE conditions and LIMIT.

Example

An interface uses an Agent Database adapter in Polling mode with this SOQL query:

SELECT Id, Name
FROM Account
WHERE BillingCountry = 'Cambodia'
LIMIT 5

The customer calls invokeCalloutV3 with 10 Account IDs: 6 Accounts in Cambodia and 4 in Vietnam.

• Before: SKYVVA could create polling messages for all 10 Accounts.
  
• After: SKYVVA creates polling messages for 5 matching Accounts in Cambodia, respecting the country condition and record limit.

Only the selected records are prepared for the Agent to retrieve and send to the destination system. Customers can control this selection through the interface’s existing SOQL query.