SK SKYVVA Documentation

2. Bug Fixed

Fixed: Reprocessing API Message Created in SYNC Mode Shows Null Pointer Error

We fixed an issue where reprocessing an API message created using invokeCalloutV3 in SYNC mode could update the message comment with the following error:

API Message, 205, Message: Attempt to de-reference a null object

This happened during message reprocessing when the outbound interface used a REST Adapter and a Fault Interface/response handling flow. The original API response was returned correctly, but after reprocessing the same IMessage, the comment could be overwritten with the null object error instead of keeping the correct backend response message. The issue occurred because the reprocess flow could run without the original CallOutControl input parameters, and in some cases, the configured Fault Interface relationship was not loaded when the REST response was processed again. The reprocessing logic has been improved so that V3 outbound REST messages created in SYNC mode can be reprocessed consistently. Missing callout control parameters are now handled safely, and the Response/Fault Interface is loaded correctly during inbound response processing. After the fix, reprocessing preserves the correct backend response handling and no longer fails with the null-object error.

Fix null value export when “Don’t Export NULL value” is enabled for Rest Adapter

Fixed an issue in the REST Adapter where outbound payloads could still include formula-mapped fields with null values, for example, "FieldA": null, even when Don’t Export NULL value was enabled. The REST payload generation logic has been updated to correctly skip formula-mapped fields when the formula result is null or blank and null value suppression is active. This ensures REST outbound payloads follow the configured null export behavior correctly.

Fix Sage GET Response Interface processing for native scheduler/manual execution

Sage GET interfaces executed from SKYVVA Manual Processing or Scheduler received a successful HTTP 200 response with data, but the linked Response Interface was not invoked. No inbound response messages were created, and the expected Salesforce records were not created or updated. The problem happened because Sage pagination/response handling was hardcoded to check the $resources response node. When the API returned business data under another node, such as data, SKYVVA treated the response as empty/end of pagination and skipped response processing. This issue has been resolved by updating Sage100 GET pagination to support a configurable Business Data Field Name, with $resources as the default value. The adapter now checks the configured response node to decide whether business data exists and whether pagination should continue or stop. The previous logic that skipped inbound processing when $resources were missing or empty was removed, so successful GET responses can continue to the linked Response Interface correctly.

Fix callout execution when the interface has no adapter

After the upgrade, customer Apex test classes that called IServices.invokeCallout failed when the outbound interface did not have an adapter linked. The failure happened because SKYVVA checked the adapter inactive status even when the adapter record was null, which caused the callout flow to break. This issue has been resolved by updating the adapter inactive check to safely handle a missing adapter. If no adapter is linked, SKYVVA no longer treats it as an error during this check. Added test coverage for callout execution on an interface without an adapter to prevent the regression from happening again.

Fixed Scheduler Last-Run Date/Time Fields in Adapter Mappings

Fixed an issue where adapter mappings using SKYVVA scheduler virtual fields did not work correctly during scheduler or batch execution.

Affected fields include:

These values are generated by SKYVVA at runtime and are not real Salesforce fields. Previously, when SKYVVA rebuilt the mapping source data from message records, these schedulers' last-run values were missing. As a result, mappings that depended on the scheduler's last-run date or time could not use the values correctly.

This issue has been fixed. SKYVVA now adds the scheduler's last-run date/time values into the mapping source data before executing the mapping logic.

A follow-up correction also ensures that these virtual fields are only added when a valid last_run_date exists. This prevents incorrect default values from being added when there is no previous scheduler run.

With this fix, scheduled and batch adapter mappings can correctly use SKYVVA scheduler last-run date/time values.

Fixed Scheduler Last-Run Date/Time Fields in Adapter Mappings

There is an issue while Data Loader export could miss fields in XML/JSON output when the mapping used Copy Node. The Data Loader mapping result stored values only by the plain Target_Path__c, but the XML/JSON builders look up Copy Node values using Target_Path__c + Copy_Index__c. Because the copy index was missing from the generated key, the builders could not find those mapped values, so copied node fields were dropped from the exported payload.

This issue has been resolved by append Copy_Index__c to the mapping result key when a mapping uses Copy Node. This makes Data Loader output use the same key format as the XML/JSON builders expect. Added regression test coverage to confirm copied node values are preserved during export.

Fix Data Loader XML/JSON export with Copy Node mapping

There is an issue while Data Loader export could miss fields in XML/JSON output when the mapping used Copy Node. The Data Loader mapping result stored values only by the plain Target_Path__c, but the XML/JSON builders look up Copy Node values using Target_Path__c + Copy_Index__c. Because the copy index was missing from the generated key, the builders could not find those mapped values, so copied node fields were dropped from the exported payload.

This issue has been resolved by append Copy_Index__c to the mapping result key when a mapping uses Copy Node. This makes Data Loader output use the same key format as the XML/JSON builders expect. Added regression test coverage to confirm copied node values are preserved during export.

Fixed Browse Log File Loading and Delete Support

Open this article in the interactive viewer →