With this release we introduce feature fields for the mapper Developer mode. You can open and examine the component input metadata and add needed objects by clicking on it. You can also add the path to property if using function or expression.
Animation above shows an example of these fields while configuring the email component.
As an integrator or component developer we need to dive into the troubleshooting and debugging sessions to identify and iron out some problems in our projects. For this purposes, the detailed logs are invaluable. On the other hand, detailed logs are sometimes unnecessary during the normal operation runs if you tend to exchange sensitive data through your integration projects.
To control the logging level for each of your flow-step we introduce a new setup called Log Level, accessible from the Advanced Setting part of flow-step Summary. With this setup you can increase or decrease the output logging level of your component from the default Info using the drop-down control shown below.
Please Note: To change the logging level of any flow-step, you must create a new draft for your flow, save it and start again.
The available logging levels are Trace, Debug, Info, Warning and Error where the Trace will output everything your component can show. On the other end of this spectrum, the Error level would output only the flow-step errors.
You can set or change the logging level directly using our REST API call. For this
purposes we extended the flow step configuration by adding the log_level
parameter:
"attributes": {
"nodes_config": {
"step_1": {
"log_level":"info"
}
}
}
Please Note: You can only change the logging level for run-time executions. This setup would not work on one-time executions like retrieve sample and verify credentials.
During some exceptional circumstances, you might get too many errors in your flow execution step to retry it one-by-one. To help process these errors in one go we introduce a new option Retry All Errors which will appear if more than one error happens in this step during an execution.
When clicked, our system will ask you to confirm your action by displaying you the following popup message:
Note: the error messages will be deleted from this Runlog Record. Retry results will arrive to this Runlog record.
You can cancel and return to your screen with errors or confirm and retry all errors, in which case our system will retry all retriable errors. This feature has a limitation: you can’t edit messages before retrying while using retry all errors.
Please Note: Only messages in the single step of particular executions will be retried. It is not possible to retry errors from all steps or from all executions of the flow. For that you still need to open each step in particular execution separately and press retry all button.
With this final release of the year 2020 we announce the end-of-life for our old mapping experience which was with us for several years and served us well.
From this release the new mapping experience will be the default and it is no longer possible to switch-back and forward between them.
Please Note: If you still need to use the old mapping experience and you are one of the OEM customers get in touch with us - we can enable it for your tenant.
With this release we introduce next sets of improvements to the Node.js Sailor, the base library used to compile any Node.js based component code during the platform deployments.
Component Developers Note: Use Sailor version
2.6.21
along with the Node version12.20.0
or higher for these improvements. Details follow.
Starting from the Node.js Sailor version 2.6.19+
, we improved the mechanism used
in the connection to and from the RabbitMQ queues and the pods running your component
code.
AMQP_RECONNECT_ATTEMPTS
- number of retries on connection close.AMQP_RECONNECT_TIMEOUT
- delay between connection retries.WAIT_MESSAGES_TIMEOUT
- delay between next poll when queue is empty.Starting from the Node.js Sailor 2.6.21+
, the rebound message headers and the rebound
message expiry time inconsistencies are fixed.
You can now configure how long it would take the one-time execution to timeout
and severe the connection with the third party resource. We introduced a new
variable FORCE_DESTROY_ONE_TIME_EXEC_SEC
to control the timeout.
To use this functionality add/change force_destroy_one_time_exec_sec
ksonnet
parameter in the config.json
file and write your desired time.
The default is 120 seconds.
We introduced tenant setup parameter flag tenant.feature_flags.old_mapper_enabled
to control visibility of the switcher between old/new mapper. With this release
the flag is set to false
by default.
As an OEM customer you can still enable and use the old mapping experience.
Use the tenant setup parameter flag tenant.feature_flags.old_mapper_enabled
with true
value. Check our API documentation for /v2/tenants
endpoint parameter flags.
Lookup by field
configuration field depended on Object
field in the component action.ETIMEDOUT
, ECONNRESET
etc.2.6.21
.2.6.19
Finalize Opportunity
is added.Request Opportunity Review
is added.Create Objects
action. In particular Opportunity
. Opportunity Item
and Lead.
Update Object
action: Opportunity
, Opportunity Item
, Company
amd Lead
.Update Object
(Company object type) and Lookup Objects
(Company object type).As a part of the annual component code audit for a possibility of sensitive data exposing we checked and updated the following component codes and the dependencies: