You can choose the SKYVVA operation to define which kind of operation the interface should do. For example, we support CRUD operations: INSERT, UPDATE, DELETE, and UPSERT. Furthermore, specific SKYVVA operations like query or pullQuery can be set. As of now, we have also implemented the new operation type beside the classical operation as mention above. We have added three operations such as Autolaunched Flow, Apex class, and Publish Salesforce Event. The new operation is more powerful as it can handle the user custom business logic.
Currently, we support different interface operations for the inbound and outbound interface as following:
|
Operation Type |
| 1. Upsert |
| 2. Update |
| 3. Insert |
| 4. Delete |
| 5. Query |
| 6. Pullquery |
| 7. Upsert Auto External Id |
| 8. Update Auto External Id |
| 9. Delete Auto External Id |
| 10. Autolaunched flow |
| 11. Apex class |
| 12. Publish salesforce event |
| 13. Query All |
| 14. REST Query |
| 15. REST Query All |
| 16. Bulk Query |
| 17. Bulk Query All |
| 18. Store Procedure |
DML Operation: #
You can use DML operation to Upsert, Update, Insert, and Delete Salesforce records.
Upsert: #
This operation will create a new record and update the base of the existing record on External mapping value. SKYVVA checks the record in Salesforce by external value if the records do not exist then create a new record otherwise will update.
Update: #
SKYVVA will check the records inside Salesforce base on the external value then update those existing records.
Insert: #
As for this operation type, it will only create a new record in Salesforce.
Delete: #
This operation type will delete the records in Salesforce base on the external value.
Specific SKYVVA Operation: #
Query: #
With our operation Query, you can send data in JSON to the receiver. The query operation is using to retrieve the sObject data from Salesforce, an external system such as SOAP client, PostMan, etc. However, for PostMan we use the REST version, as for SOAP we use SearchService API. You can query the data by using SOQL statements and write SOQL by entering the outbound interface. Likewise, you can use a query editor to generate SOQL statements in our outbound interface.
Query operation gives the response as JSON string back to the client. We have two possibilities to query the data:
- Query operation without mapping to get the row data as a result. If you do not add, a mapping then just the SOQL result will be sent as JSON payload.
- Query operation with mapping will give the enhance data or manipulate the data through the mapping as a result. You can add mapping and overwrite the value of the selected data from the database.
Previously, you can only use operation query to mapped sObject structure, which is the target structure as well. To map the result of SOQL statements to other structure is impossible. However, we have enhanced this operation to be more flexible to support any target structure ( free define structure). Now you can do a mapping from the sObject structure to the target structure, which can be also structure we have created as the message type.
The structure on the target side could be the following:
- sObject structure which is the same as the sObject we specify in the field ‘Source/Target’.
- Any message type from the repository
- Any Istructure fields we have uploaded or manually created for that outbound interface
[su_box title=”Note” box_color=”#e0ddbb” title_color=”#00000″] Operation Query now can also modified the result through mapping engine.
[/su_box]
pullQuery: #
When we query data, we get a result, and then next time we query again we get the same result and it sends back to the client again. pullQuery operation is used in combination with an outbound interface and it is used within interface outbound Scheduler. The Scheduler can execute the outbound interface, select the data, and send the data back to the receiver. We use pullQuery operation as if we do not want to send the save data again which is sent once already. Therefore, by this pullQuery operation, we will send data only once. For this, we need to create a custom field on the Salesforce object.
Auto Operation: #
As you know that SKYVVA is already supported with both “External Id as Key” and “Salesforce Id as Key”, however, we are not able to handle the mix key value. Auto operation is implemented to handle dynamic key and it will combine between “External Id” and “Salesforce Id”. You can use this operation to Auto Upsert, Update, and Delete the records based on Salesforce Id or external fields, which is, specify on the interface. As of now, Integration3 is supporting Auto Operation the same way as CRUD operation. Integration3 can handle this operation automatically when the record contains the Salesforce Id. You do not have to explicitly select any Auto operation, just select UPSERT and it can handle it automatically when the record contains either the Salesforce Id or external Id for processing.
Upsert Auto External ID: #
It will auto upsert record base on salesforce Id or external Id field.
Update Auto External ID: #
When you choose this operation it will auto-update records base on Salesforce Id or external Id field.
Delete Auto External ID: #
When you choose this operation it will auto delete records base on salesforce Id.
[su_box title=”Note” box_color=”#e0ddbb” title_color=”#00000″]This operation improves the performance because an update with a dedicated key is faster than upsert where a search has to be performed first to find the record. If a Salesforce Id is provided directly there is no search needed. [/su_box]
SKYVVA New Operation: #
Besides just doing the database operation SKYVVA has implemented the new operation to execute the posting processing after the mapping step. We redesign our inbound processing flow as the user can now put in their custom logic to replace our step or just plug-in their custom logic to SKYVVA/their steps. It allows you to handle your customs business logic as you wish. Those operations are Autolaunched Flow and Apex Class. These two operations have the same purpose, as SKYVVA will pass data and message to you after you are done performing your own business logic. You later must update the message status and return to SKYVVA. After returning the data, we update that message for the user to check those operations fail or success. However, Apex Class is implemented for the programmer, and require writing his or her own code. As for Autolaunched Flow, create for nonprogrammer. The final operation is to Publish Salesforce Event, which creates to consume the platform event.
This table is showing the old and new processing flow
| Old processing flow: | New processing flow: |
| · Creating pending message | · Creating pending message |
| · Workflow | · Workflow |
| · Mapping | · Mapping |
| · Processing (upsert, insert, deleted, and update of sObject in the interface) | · Invoke Salesforce Flow (whatever logic you want to do here. It is your own stuff). |
