Use external Javascript functions to generate the telemetry for simulated devices. The path of folder that contain the Javascript files can be configured, so it's possible to mount JS files from anywhere. Files are loaded at runtime. The name of the files is specified in the Device Type JSON files, which are managed in the same way, with a configurable path and loaded at runtime.
Javascript files are interpreted using Jint https://github.com/sebastienros/jint .
Documentation here: https://github.com/Azure/device-simulation-dotnet/wiki/Device-Types
Remove Akka and use .NET Thread Pool to manage multiple threads sending telemetry. The lack of Akka means some extra work that we'll need in order to distribute the simulation over multiple servers. For the time being, we assume that the simulation runs in one instance only. If Akka's move to .NET Core is ready we can move back to Akka, otherwise we need some partitioning logic to distribute the load over multiple machines.
Upgrade the project to the latest template, e.g. scripts and documentations. Minor fixes for cross-platform development (VS2017 and Rider).
Complete the /status endpoint to check if IoT Hub Manager is available. In order to run the simulation, IoT Hub Manager is required. Without this check, it was too difficult to debug whether the service could connect to IoT Hub Manager or not, particularly when using Docker Compose.
Added Docker Compose file, to bootstrap this service and IoT Hub Manager containers. Add script to publish to Docker Hub. Move Docker image version/tag to a version file, so that the version is not hard coded in multiple places.
Fix an issue with the logger using too much memory when serializing exceptions.
Improve handling of exceptions caused by unreachable external dependencies when using the HTTP client.
Upgrade source code, project files and scripts to use .NET Core. Mono is not required anymore, and also the Docker image will now use only .NET Core.
The configuration format has changed to be in line with ASP.NET Core configuration providers.
The simulation runner is temporarily disabled, because Akka.NET is not ready for .NET Core, and I'm in the middle of removing Akka from the project as well.
Due to the move from .NET Core, some internal APIs are different, for instance you might notice changes in the web service exception filter, in the Autofac dependency injection setup, in the use of Kestrel as a HTTP server.
Since the microservice is now built and packaged with the `dotnet` command, some paths have changed, and scripts have been updated accordingly. I tested the scripts in Windows and MacOS, hopefully catching all the edge cases. The scripts are now actually simpler, which is a nice and unexpected result of the migration.
* Remove Akka HOCON from web service, use app.confg for settings - use HOCON only when using Akka
* Improve config parsing
* Add Moq to all test projects
* Add env var for IoTHubMan web service
* Update env vars management and correlated scripts
* implement simulation agent using Akka actors
* update Docker scripts to package the web service and the simulation agent
* some DI refactoring to align web service and simulation agent
* detect and manage content negotiation errors
* Change ERRORLEVEL code in Windows scripts
* Change windows scripts error redirection
* Fix compilation warnings and convert some *nix scripts to ISO
* Document the exceptions and apply filters on controllers (rather than globally)
* Add new endpoint to list all the supported device types. Device types are configured via JSON files external to the assembly, so that users can add custom types without rebuilding the service. The files include a README describing the format of these files.
* Add simulations storage and endpoint with input validation and error handling. Supports creating a default simulation.
* Improve performance by using singletons
* Add missing property in the Status endpoint
* Make sure the temporary storage is usable when working in an IDE
This adds a new endpoint to list all the supported device types. Device types are configured via JSON files external to the assembly, so that users can add custom types without rebuilding the service. The files include a README describing the format of these files.
I was going to use HOCON for these files too, for a cleaner look, but I'm actually reconsidering that approach and the use of Newtonsoft greatly reduces the code required to parse these files (at least in .NET).
Devis Lucato
Devis Lucato
Devis Lucato
Microsoft Open Source
Microsoft GitHub User