Adapter Microsoft Dynamics NAV
The Microsoft Dynamic NAV adapter is defined in the Microsoft Control Board. This means that the on-cloud and on-premise variant that doesn’t use the agent as the middleware is defined in the Microsoft Control Board. When the Agent should be used as the middleware for the on-premise deployment for Dynamics 365 xx, NAV, and AX then we are using the Agent Control Board and the Agent Microsoft Dynamics 365xx, NAV, and AX adapter from there. Microsoft Dynamics NAV Server supports a range of different client types.
- Direct connection from Salesforce to NAV
- Indirect connection from skyvva to NAV through the Agent.
Adapter SAP Business One
In Skyvva, we have a new feature to send out data from Salesforce to SAP Business one client application by using SAP business one adapter. This adapter has worked with different SAP business modules such as Business Partner, Sale, Purchasing, and many modules in Sap Business One. This section will show how to use SAP Business One Adapter. To use this Adapter we need to have SAP Business one connection destination and we need to generate SAP Business One Message Type. This Adapter supports Dynamic URLs, PATH Parameter, QueryParamenter, and multiple operations such as POST, GET, PATCH, DELETE.
SAP Business One Adapter is used for Request and Response processing by using SAP business one Message type.
Transactional mode is a flag that we can set as true or false. “IsTransactional__c=true” Means that when a node has failed then it will roll back the whole tree.
There are two modes:
- Transactional Mode
- -Non-Transactional Mode
Transactional Mode :
When the Transactional Mode flag is ON, and a node failed then it will roll back the whole tree. Let’s take an example, We have three level messages account, contact, and asset
In case of non-transactional message failed whole tree message is not working Let’s take an example of Non-transactional, we have three level messages account, contact, asset when asset failed account and Contact will saw pending. This will convert:
- Handle complex objects as a logical unit
- Post a complex object ‘All or Nothing‘
- Partial creation in Non-Transactional mode
- Prevent multiple API calls for a complex object
- Commit or Rollback
Enhance the chain operation to a new value ‘Delete + Upsert’
The feature with our inti operation for the chained interface is to handle the deletion of a child from the sending system. There are different init-operation for the chained interface as per the condition. If we want to use this operation, we need to edit Init Operation in Ichain Interface
Google Drive connector
Google Drive is a cloud storage service that allows users to save files and access them from anywhere. From SKYVVA v2.48, we have the capability to allow the users to back up their data directly from Salesforce to keep on Google Drive. Besides sending data to google drive we can also read data from Google drive back to Salesforce. The user can transform their data to any file format such as CSV, XML, or JSON. They can save their data to Google Drive manually or automatically from our Control Board.
Microsoft OneDrive connector
This adapter will help to store and protect your files, share them with others, and get to them from anywhere on all your devices. This adapter will be used to create CSV, EXCEL, XML, and JSON files inside the Microsoft one drive folder. Here we need to create Microsoft account, Azure account and tanent.
Dropbox is a file hosting service, often referred to as a “cloud storage” service. Dropbox is one of the oldest and most popular cloud storage services in use today, though there are many alternatives, including Microsoft OneDrive, Box, Sync, and Google Drive.
This adapter will be used to create CSV, EXCEL, XML, and JSON files inside the dropbox drive folder.
Enhance v4/integrate API to support CSV
Our V4/integrate rest variant supports JSON, XML, and CSV therefore it is possible to pass the Rest envelope XML or JSON or CSV to the body of the v4/integrate. This means that for invoking the skyvva API we use only the rest variant../services/apexrest/skyvvasolutions/v4/Integrate with either XML or JSON or CSV payload.
In the URL of V4 API, the query parameter is added in URL only.
We have two types of response:
1. standard response
2. response using the response (outbound) interface to do the mapping
Enhance the interface execution scheduler to handle response handling and create a group scheduler :
When the interface with mode = Synchronous to process the response in apex future, queueable and batch. This means that the outbound will link to an inbound interface and the interface mode = Synchronous. In this case, an outbound execution interface scheduler is created to also process asynchronous interface.
We already have the scheduler created on the interface level e.g. for each outbound interface with the interface mode = Asynchronous a scheduler will be created. Now We have the same scheduler on the interface group level. The scheduler executes all interfaces one after the other based on the interface group sequence which the user defined while they add the interface into a group.
Add a new operation ‘Create New Message’ for the inbound API
We have to add a new picklist value ‘Create Custom Message’ as the Operation type.. The message can be any payload format like Text, CSV, XML, JSON, or binary. The user just wants to configure on the interface a new operation mode like ‘Create New Message’. We get the raw message and we create the message with the status ‘New’. Then we stop the processing.
On the interface sObject add “Create Custom Message“ to the existing picklist for the field “Operation Type“. This new operation type allows the user to create a so-called custom message that will not be processed by the Sykvva processing engine. The data is just stored as a message in the Skyvva message layer and your custom apex code is to use to process the message.
On the message sObject add a new picklist value “Custom Message“. This is the new category of the message that indicates our processing engine not to process it with our standard logic. The customer wants to have his own custom logic to process the message.
Supporting for the Data Loader to support json additional to CSV and XML format.
SKYVVA´s Dataloader is a native Salesforce App and is designed to integrate data supporting CSV/XML format via a manual file upload. It is simple, intuitive, and powerful to build integration in minutes. It is a Config&Click graphical mapping tool. Skyvva data loader is used to upsert, insert, update, delete, or export Salesforce records. Data Loader is running in Bulk mode. If we want to send data to email, we can check the flag batch mode. But to use this mode we need to make sure that we have library SKYVVA__Workspace. If not go to create it.
New fields on the interface to define the field for the Transaction Id and System External Id.
We need only to add two new parameters e.g. ‘TransactionId’ and ‘SystemExternalId’. The transfer Id we hard assign with the SAP-PO message. In the parameter ‘TransactionId’ and ‘SystemExternalId’ the user needs to specify a field name from the XML payload that he wants to use as the transaction id. He has to specify the full path to the field so that we can fetch the value by using the full path. The responsibility is at the user side to use only fields that contain a unique value for the transaction or the system external Id. For example when the SAP-PO message contains an idoc then the idoc number can be used as the system external Id. Then the user has to specify the field + full path where to read the idoc number. Note in SAP-PO mapping we have mapped already the idoc-xml (source) to the Salesforce XML (target) and therefore our module will get the target field name. The user has to specify the target field name where he has mapped the idoc number and the full path. For the transaction Id, the user can set the field from the target payload (after the sap-pi mapping) as well if needed. But in most cases, we don’t need to specify the transaction Id because it is generated inside Skyvva automatically. But if it is needed then he can specify the transaction If from a unique key value from the target payload.
New picklist value on the REST adapter to choose if the Salesforce Id is to be put into the response or not.
Add new field property on the Rest Adapter. The type of this field is picklist. This field property is optional. The default value is None: we always return the Salesforce Id back in the response
the User needs the Response to create a new record on Salesforce, We can do operation Update or Delete base on Salesforce Id. Then it will create a new record from the response due to some cases, the response can be a list and then the User needs to create a new record.
Enhance the and batch and bulk processing to limit the number of files that we select to process in a scheduler run.
There are big changes regarding batch and bulk processing. We have made some changes to the screen and also to the processing. For example, for the bulk, we now use the batch object to link to the content version and we don’t process the content version or Attachment object directly anymore. Instead, we are processing the baskets which are linked to the content version. Note that from this version 2.48 we don’t use the old attachment anymore. We use only the content version sObject to store the business data.
The counting has been redesigned due to a governor limit error in the old logic while trying to count the number of records in the basket. The new logic solves this issue.
HTTP header field in the adapter become a multi-line
In all adapters where you can set the http header fields, we have changed from a single line to a text area. Before you have to separate the different http header parameters by a semicolon. With the new version, you have to use a new line to separate each http header parameter. If you have used the old version with the single line option you have to replace the semicolon with a new line. If you don‘t make this change the http header parameter will not work with the associated adapter.
Old field SKYVVA_EXTERNAL_ID__c change to new filed skyvvasolutions__system_external_id__c
In the previous version, we have used the field ‘skyvvasolutions__SKYVVA_EXTERNAL_ID__c‘ to store the so-called system external id. A system external id is for example the sap idoc number or the SAP-PO message number. This Id can be transferred to Skyvva to use for search in the monitoring. Due to some conflict, we have changed this field not to use for this purpose anymore. We are using the new field ‘skyvvasolutions__system_external_id__c‘. Our own client as for example the Agent, SAP and SAP-PO Connector we have changed. But if you are using our API with this old field you have to change to use the new field ‘skyvvasolutions__system_external_id__c‘ instead of the old field ‘skyvvasolutions__SKYVVA_EXTERNAL_ID__c‘. If your client doesn‘t use our API then there is no impact on your side.
Process Builder/Flow Invokes Apex To Create Change Pointer/Execute Outbound Interface Version 3
Flow executes SKYVVA apex to create change pointer. We provide the possibility to invoke SKYVVA Api to create changed pointer or process outbound interface from Flow (record triggered flow). User must have an outbound interface and check flag Use SKYVVA Outbound Scheduler on that interface.
Process Builder is used to create CP record and show in CDC Control Board using invoke callout3(). Like flow, we must have outbound interface and check flag “Use Skyvva Outbound Scheduler” on that interface