4.5 Release Notes - 24th October 2017
FRENDS 4.5 has new features especially targeted for hybrid integration scenarios, where you have on-premise and cloud agents that will need to communicate with each other. FRENDS 4.5 also allows you to expose APIs from a separate API gateway agents that are easy to install and manage.
Easy communication between cloud and on-premise agents
Some integration situations require you to combine both on-premise and cloud environments: e.g. you need to expose an API from the cloud, but the API operation needs to update something in your on-premise systems. You wouldn't want to setup a VPN connection, specific authentication etc. from the cloud environment to the on-premise servers just for this update action. In FRENDS 4.5, you can easily implement a solution for this, because now you can execute subprocesses on other agents, e.g. calling a subprocess running on an on-premise agent from a cloud one.
In order to manage processes running on different sets of agents, the agent environment model has been changed slightly: Agents now belong to Agent groups, and you can have more than one Agent group per Environment. This way you can have a logical "Production" Environment with separate Agent groups based on the actual deployment infrastructure, e.g. "prodDMZ", "prodBackend". You deploy and execute Processes on specific Agent groups, and Processes can then call Subprocesses from other Agent groups within the same Environment. This means e.g. that an API process running in "prodDMZ" can call a Subprocess running in "prodBackend". All communication happens via the secure FRENDS message bus, so there is no need to open ports or setup VPNs.
API Gateways
In FRENDS 4.5, Agents can also run as API gateways. In this reduced gateway mode, the Agents will only expose any HTTP or API triggers, authenticate the requests and then pass the call to the internal agent actually executing the processes. The gateway Agent can also do simple load balancing, and will also authorize and throttle requests the same way as your actual execution agents. This way your actual execution Agents will not be burdened with too many requests.
You can also mark your API processes as private, which means they will not be exposed from a gateway, but only from the internal executing Agent. This allows you to keep your internal APIs only available from within your network.
Usability fixes and tweaks
There are also many minor features making the product easier to use:
Process list rendering performance is now a lot better, allowing you to view hundreds of process rows at a time, if you so wish.
You can copy the actual JSON result structure returned from a task step, so you can more easily verify it or store it separately.
You can set specific dates in a schedule trigger to run a Process only on the given days.
Upgrade notes
During upgrade, the log database tables are migrated to include the AGENT_GROUP_ID column. If you have a lot of process instances in the log tables, this may take a while.
4.5.1 - 2nd November 2017
The first maintenance release fixes a compilation problem as well as many UI issues:
Compiling processes with Linq expressions failed with "You must add a reference to assembly 'System.Runtime'
Copying while or foreach scopes to a process editor in another tab failed
Cannot change log settings for older version of process
Calls to Trace.WriteLine in custom tasks logged as errors to Event log
4.5.2 - 30th November 2017
The second maintenance release fixes performance problems as well as many UI issues:
Running hundreds of file triggers on an agent could exhaust SQL connection pool, also blocking other connections
Couldn’t call remote subprocesses with large parameters (>250KB)
Searches on process instance parameters or results would partly run in web server memory, causing the entire server to become unresponsive for large queries. Now the queries are done entirely in the backend database.
There was no confirmation for deleting a process
4.5.3 - 21st December 2017
This release changes the default setting which controls HTTP trigger availability on the API gateway. Previously, HTTP triggers were public by default, the same way as API triggers, i.e. available on the API gateway. However, in many cases you actually did not want to expose the existing HTTP triggers (e.g. for internal APIs) on the gateway, which may be running on the DMZ.
Therefore, the HTTP triggers are now private by default, and you need to change them explicitly to "Public" to expose them on the API gateway. All HTTP triggers will still be accessible on the non-gateway agents. API triggers will still be public and exposed on the API gateways by default, as before.
The release also fixes issues with intermediate results as well as some UI problems:
Intermediate results did not actually return to the caller if the next step was a synchronous call, such as a subprocess call.
Intermediate results could not return custom HTTP results.
API management list did not correctly show process links if the operation path case had changed.
You can now also filter the process list to show only those processes with executions or errors since the given number of days, as you could in version 4.4 and before.
4.5.4 - 30th January 2018
As a highly requested improvement, this release brings support for returning binary results from HTTP triggers. For more details, please see HTTP Response results here.
This release also has a lot of UI and performance fixes, such as:
Old process instance cleanup procedure timed out if there were millions of rows already in database. With an improved index, the performance should be much better
Loading the process list was slow if you had hundreds of tags or tasks. The queries are now better optimized to return only the data needed for the list
Scheduler UI did not correctly update monthly type selections, leading to invalid schedules
Monitoring rule data series got generated with different offsets during daylight savings changes, causing false alerts. Now the rules will ignore any DST changes, and use only the base offset for a timezone
4.5.5 - 14th February 2018
This release fixes UI issues, and improves the initial load performance of the process list:
Navigation bar didn’t always show available actions for the first initial requests after signing in. Now the cookies are set correctly.
Process list now fetches the execution counts only for the last 7 days by default, to reduce loaded data amounts and improve performance.
Service bus trigger now allows you to fetch messages in a batch. Turning batching on will greatly improve performance when processing lots of messages.
Return and throw shapes now allow you to set an expression as the return value.
4.5.6 - 9th March 2018
Custom task package users and developers should note that 4.5.6 now also supports System.ComponentModel.DataAnnotations attributes for specifying how you want your custom task parameter editor to look, i.e. having tab panels or optional input fields. Previously, you were supposed to use the attributes from the Frends.Task.Attributes package, but due to versioning issues, using two different versions of that package seems to cause problems during task import as well as task execution not being logged correctly. Therefore, the Frends.Task.Attributes package has now been deprecated, and all new custom task versions should use the ones from System.ComponentModel.DataAnnotations. Existing tasks will still work as before, but all new task versions should use the new attributes. Please see the documentation for more.
The FRENDS platform tasks (Frends.Web, Frends.Json, etc) as well as Frends.Cobalt have also been updated to use the new attributes. Please note that you should only update to the latest versions once you have updated to 4.5.6, otherwise the task parameter editor may not look as you’d expect.
The release also has other fixes, e.g.:
Deleting an API spec from an agent group not named the same as the environment now works
The API management view will now show a warning if an agent group has a deployed API process without a matching API spec deployed (ACC-6628)
Importing an API spec no longer requires access to http://json-schema.org.
Enum parameter values are now migrated correctly to the new editor format from existing 4.2 processes.
The file share paths for large message store etc. are now validated on service startup.
4.5.7 - 12th April 2018
This release improves subprocess thread usage and execution performance, especially when there is a large spike in number of executions running at the same time. Please note that in order to take advantage of the subprocess call performance improvements, you need to recompile the processes that call subprocesses.
There are also many fixes to the UI and other issues like:
Trigger editors could be slow to open if you had a lot of environment variables. Now the trigger parameter inputs use the same, more efficient editors as task parameter inputs.
Processes that were automatically updated when upgrading a task package could not execute due to metadata not set correctly.
Using different versions of Newtonsoft.Json package in task packages now again works.
4.5.8 - 22nd May 2018
This release fixes two major issues:
Subprocess call parameters were not always released correctly, causing memory usage to keep growing. Please note that to apply this fix completely, you will need to recompile and deploy new versions of the processes calling subprocesses.
When running file watch triggers on two or more agents, the trigger could start a process twice for the same file, if the file was still being written to when the first agent noticed it. If the second agent then noticed it with a slightly different size, it could also start a process.