Add new controllers to custom apismaster#186
Conversation
Reorganized imports, included PhasorWebUI namespaces, and improved comments. The AuthenticationOptions property was moved to the beginning of the class with documentation. Added instances of the DeviceController, PhasorController, and DevicePhasorController controllers. Adjusted formatting, removed duplicates, and improved organization of static members.
Includes DeviceController, PhasorController, and DevicePhasorController for querying devices (PMUs), phasors, and their relationships, with endpoints for filters and CSV export. Adds StringConstant.cs to standardize field names. Updates the project to include the new files and implements structured logging in all controllers.
Includes the DeviceWithPhasors class as a DTO to represent a Device (PMU) with its list of associated Phasors. Adds the new DeviceWithPhasors.cs file to the openPDC.Model.csproj project.
Comments for the DeviceWithPhasors class have been translated from Portuguese to English, improving documentation and making it easier to understand for international developers.
The driver's XML comment has been reformatted for better readability. In the GetDeviceWithPhasorsByAcronym method, the phasor query has been simplified by removing sorting, limit, and offset parameters, using only the acronym filter.
…thub.com/eduardocordova21/openPDC into add-new-controllers-to-custom-apismaster
The CSV header now includes the "IsConcentrator" column after "ProtocolName". The corresponding value is required for each device, both those with phasors and those without phasors.
|
These new suggested controllers are an interesting addition, were you hoping to use these new controllers to support a new UI or similar function you are developing? Right now, most of this functionality duplicates the available record I/O operations defined in the Your PR code looks very clean and I have tested it -- everything seems to run OK. FYI, should we accept the PR, there may be a few minor suggestions we request related to code style, etc. just to match general openPDC coding patterns for ease of future maintenance. Additionally, we would likely want to migrate the controllers to a library in the Grid Solutions Framework so the controllers could be used in openPDC as well as openHistorian, both of which expose similar web service functionality. Even so, instantiating the controllers in the One thing to note is that since these controllers sit behind openPDC's security apparatus, access to the exposed controllers will be based on the authenticated openPDC user which makes access to the controllers secure. This is good, but this also means the REST web controller consumer tool or UI must be authenticated as an openPDC user in order to use the REST web service. This works naturally if the UI or tool consuming the controllers also sits behind the openPDC web service, with user logging into the openPDC web UI first, but it might be otherwise cumbersome if the controller consuming UI tool exists outside the openPDC web service, because: (1) the openPDC would need to be configured to allow CORS-based access to the consuming external application, and (2) use of the controllers would require an openPDC user to first authenticate the web service with a web browser -- OK for a UI, but not ideal for an automated tool. So, this is something to consider, and gets back to the main question, i.e., were you hoping to use these new controllers to support a new UI or other function? Currently the controllers appear to be read-only so any controller consuming UI tool would be limited to viewing data only. Allowing the addition of these controllers into the openPDC/openHistorian/GSF would need a defined purpose -- so let's further discuss the target use case you had in mind here. Thanks! |
Includes endpoints in the DeviceController to insert/update devices and import via .PmuConnection, with parsing, connection to the PMU, and phasor persistence. Adds a Phasor class to the model and references to the projects.
Updates methods in DevicePhasorController.cs and the DeviceWithPhasors class to use the Device entity instead of DeviceDetail, impacting device queries and handling.
Implements a routine to automatically create and update measurements for each PMU/PDC configuration cell, including frequency, dF/dt, status, phasor, analog, and digital signals. Adds auxiliary methods to retrieve SignalTypeID, describe signals, and perform measurement upserts while preserving the SignalID. Expands ProcessAllCells and improves code logging and organization.
Implemented import flow via .PmuConnection that allows automatic resolution of company, historian, manufacturer, and interconnection by readable identifiers. Added DeviceMetadata class to transport and resolve this data. Adjusted processing methods to utilize metadata and ensure correct associations. Refactored the Device class with new attributes, required fields, and improved organization to support the new flow.
…thub.com/eduardocordova21/openPDC into add-new-controllers-to-custom-apis
Includes Swashbuckle configuration in Startup.cs, generation of XML documentation files in openPDC and openPDC.Adapters projects, reference to Swashbuckle.Core.dll, and adjustment to the CSP policy to allow access to the Swagger UI.
Updates the regular expression AnonymousResourceExpression in the App.config and AppDebug.config files to include the path ^/swagger, allowing unauthenticated access to Swagger-related resources.
The Swashbuckle.Core.dll component has been included in openPDCSetup.wxs, with support for native image generation (ngen) for 64-bit platforms, ensuring its inclusion and optimization in the installer.
Refactors SaveMeasurementsForCell to preload signal types into dictionaries, eliminating repeated database queries. Aligns PointTag generation with the Device Wizard standard for PMUs, phasors, analog, and digital signals. Removes LookupSignalTypeID and adjusts descriptions and comments to reflect the new naming and query rules.
The default value of the timeoutSeconds parameter in the RequestConfigurationFrameAsync method has been changed from 60 to 240 seconds, allowing for a longer wait time for the frame configuration.
Replace DeviceDetail with Device in the methods of the DeviceController and DevicePhasorController controllers, adjusting return types, queries, and CSV export to reflect the fields of the new entity. Adapt filters by company and protocol to use CompanyID and ProtocolID.
DeviceController endpoints now return devices with associated analog and digital depth lists. The DeviceWithMeasurements and DeviceMeasurements classes have been added to structure data and optimize queries. The project has been updated to include the new files.
The GetAllDevicesWithPhasorsAsCsv method now exports not only phasors but also analog and digital measurements associated with each device. The CSV header has been adjusted to reflect the new fields and data types, including a "Type" column. An auxiliary function has been added to group measurements by device, optimizing data access.
Utility functions for handling PMU/PDC devices have been extracted from DeviceController.cs and moved to CommonController.cs, centralizing connection logic, parsing, retry, and measurement handling. DeviceController.cs now utilizes these shared methods, reducing duplication and improving maintainability. The project has been updated to compile the new CommonController.cs file.
Removes the local LoadMeasurementsByDevice method and replaces it with CommonController.LoadMeasurementsByDevice, centralizing the logic and promoting code reuse.
Removes external context dependency in LoadMeasurementsByDevice, initializes lists in DeviceMeasurements in the constructor, and adjusts calls in the controllers. Improves logging to avoid potential NullReferenceExceptions.
2 participants
This pull request introduces a new API controller for device operations and makes supporting changes to enable and register this controller in the openPDC application. The most significant update is the addition of the
DeviceController,PhasorControllerandDevicePhasorController, which provides REST API endpoints for querying device information. Supporting changes include registering the new controller in the web application startup and introducing a constants class for string values used in the adapter layer.New API Functionality
DeviceController,DevicePhasorControllerandPhasorControllerclasses inopenPDC.Adaptersthat exposes several REST API endpoints for querying device data, such as retrieving all devices, querying by acronym, company, protocol, and enabled status. The controller includes logging and error handling for each endpoint.StringConstantinopenPDC.Adapters.Constantsto centralize string constants used throughout the adapter and controller code.Application Startup and Registration
DeviceController,DevicePhasorControllerandPhasorControllerin the web API configuration withinStartup.cs, ensuring its endpoints are available as part of the application's API surface.usingstatements inStartup.csfor clarity and to include necessary namespaces for the new controller and API functionality. [1] [2]Code Quality and Maintenance
Startup.csfor better readability, especially around JSON serialization settings, CORS policy, and assembly loading. [1] [2] [3]AuthenticationOptionsproperty to the top of theStartupclass for better organization. [1] [2]