* Initial attempt at a Rust AMQP stack, merged against feature/rust_amqp for now. (#5942) * Enabled building AMQP *without* uAMQP * Start integrating Rust AMQP Value to C++ AMQP Value * AMQP Value tests now pass * Moved AmqpValueType ostream inserter to its original location * Added Rust AMQP Message implementation * Added start of message source tests * Enabled building AMQP *without* uAMQP * Start integrating Rust AMQP Value to C++ AMQP Value * Moved AmqpValueType ostream inserter to its original location * Message target support * Message source and target support * Add connection support; restructured tests to fail on RUST AMQP rather than attempting to run; removed some uAMQP-only features (#5986) * Checkpoint of connection logic * Started implementing Rust based Connection by pulling out uAMQP artifacts * Implemented AMQP Connection in Rust; started API surface refactoring for Rust APIs; Refactored tests to remove some uAMQP only elements. * Don't leak runtime context on calls * Refactor AMQP logic to better isolate rust AMQP code from uAMQP code. (#6008) * refactor uAMQP and Rust AMQP into separate implementations for ease of use * Add connection support; restructured tests to fail on RUST AMQP rather than attempting to run; removed some uAMQP-only features (#5986) * Checkpoint of connection logic * Started implementing Rust based Connection by pulling out uAMQP artifacts * Implemented AMQP Connection in Rust; started API surface refactoring for Rust APIs; Refactored tests to remove some uAMQP only elements. * Don't leak runtime context on calls * export UUID from AMQP * Cleaned up some more elements; reduced scope of doxygen significantly * runtime context needs to be process global not thread global; all tests pass or fail at this point * Merged main into branch * Implement AMQP Session APIs in Rust. (#6033) * Checkpoint of rust session support * Session begin/end now works * Session tests pass * Removed accidental regression * Added rust per-call context (#6043) * Reworked runtime context to be call context * Added context parameter to blocking AMQP calls * Added comments around the lifetime of the RustRuntimeContext captured in the CallContext object * uAMQP changes corresponding to Rust changes Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * sync rust SDK fixes to C++ --------- Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Enable Rust ClaimsBasedSecurity interoperability; Converted EventHubs producer client to work with Rust AMQP changes. (#6059) * canonicalized return values; initial CBS support * Implementation of CBS for C++ * Amqp Authentication works; Integrate Rust AMQP into Eventhubs Producer client * Implemented Rust AMQP message sender. (#6083) * Initial sender implementation * PR feedback * Management APIs work (#6096) * Management APIs work --------- Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Converted builders to be compliant with Rust guidelines. (#6102) * Converted builders to be compliant with Rust guidelines. * Bring rust changes back to C++ repo * Improved builder developer experience * Removed builders from AMQP layer to conform to Rust guidelines; Fixed AMQP bug in message sender tests (#6208) * Removed builders from AMQP layer to conform to Rust guidelines; Fixed AMQP related bug in message sender tests * Pr feedback * Implement receiving messages; Changes to eventhubs so that all eventhubs tests pass (#6254) * Eventhubs tests pass * Noise reduction; explain the task which spawns a task * Update sdk/eventhubs/azure-messaging-eventhubs/src/producer_client.cpp Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * PR feedback --------- Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Integrate Rust 2 step message receive code to C++ (#6349) * Integrate Rust 2 step message receive code to C++ * If receiving a delivery failed, transmit the error to the message channel if at all possible * Enable Rust based AMQP by default (#6362) * AMQP tests now pass; Integrate TestAmqpBroker with CI pipeline * Updated changelogs to reflect API changes made during AMQP updates * Replace uAMQP with Rust AMQP as the default AMQP transport; Updated build configurationj to reflect that * Test fixes * PR feedback; test fixes * Fixed uninitialized variable tanking some tests (#6381) * Fixed uninitialized variable tanking some tests * Fixed Rust AMQP tests * Removed connection string support from Eventhubs and EH tests. (#6391) * Removed the ability to use connection strings from EventHubs * Enable Rust AMQP by default!!! * Update CMakePresets.json Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> --------- Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| inc | ||
| src | ||
| test | ||
| vcpkg | ||
| cgmanifest.json | ||
| CHANGELOG.md | ||
| CMakeLists.txt | ||
| NOTICE.txt | ||
| README.md | ||
| vcpkg.json | ||
Azure SDK Core Library for C++
Azure::Core (azure-core) provides shared primitives, abstractions, and helpers for modern Azure SDK client libraries written in the C++. These libraries follow the Azure SDK Design Guidelines for C++.
The library allows client libraries to expose common functionality in a consistent fashion. Once you learn how to use these APIs in one client library, you will know how to use them in other client libraries.
Getting started
Typically, you will not need to download azure-core; it will be downloaded for you as a dependency of the client libraries. In case you want to download it explicitly (to implement your own client library, for example), you can find the source in here, or use vcpkg to install the package azure-core-cpp.
Include the package
The easiest way to acquire the C++ SDK is leveraging vcpkg package manager. See the corresponding Azure SDK for C++ readme section.
To install Azure Core package via vcpkg:
> vcpkg install azure-core-cpp
Then, use in your CMake file:
find_package(azure-core-cpp CONFIG REQUIRED)
target_link_libraries(<your project name> PRIVATE Azure::azure-core)
Key concepts
The main shared concepts of Azure::Core include:
- Handling streaming data and input/output (I/O) via
BodyStreamalong with its derived types. - Accessing HTTP response details for the returned model of any SDK client operation, via
Response<T>. - Polling long-running operations (LROs), via
Operation<T>. - Exceptions for reporting errors from service requests in a consistent fashion via the base exception type
RequestFailedException. - Abstractions for Azure SDK credentials (
TokenCredential). - Replaceable HTTP transport layer to send requests and receive responses over the network.
- HTTP pipeline and HTTP policies such as retry and logging, which are configurable via service client specific options.
Long Running Operations
Some operations take a long time to complete and require polling for their status. Methods starting long-running operations return Operation<T> types.
You can intermittently poll whether the operation has finished by using the Poll() method on the returned Operation<T> and track progress of the operation using Value(). Alternatively, if you just want to wait until the operation completes, you can use PollUntilDone().
SomeServiceClient client;
auto operation = *client.StartSomeLongRunningOperation();
while (!operation.IsDone())
{
std::unique_ptr<Http::RawResponse> response = operation.Poll();
auto partialResult = operation.Value();
// Your per-polling custom logic goes here, such as logging progress.
// You can also try to abort the operation if it doesn't complete in time.
std::this_thread::sleep_for(std::chrono::milliseconds(1000));
}
auto finalResult = operation.Value();
HTTP Transport adapter
Out of the box, the Azure SDK for C++ supports the libcurl and WinHTTP libraries as HTTP stacks for communicating with Azure services over the network. The SDK also provides a mechanism for customer-implemented HTTP transport adapter. You can learn more about the transport adapter in this doc.
Troubleshooting
Three main ways of troubleshooting failures are:
- Inspecting exceptions
- Enabling logging (see SDK Log Messages)
SDK Log Messages
The simplest way to enable logs is to set AZURE_LOG_LEVEL environment variable to one of the values:
AZURE_LOG_LEVEL |
Azure::Core::Diagnostics::Logger::Level |
Log message level |
|---|---|---|
4, or error, or err |
Error |
Logging level for failures that the application is unlikely to recover from. |
3, or warning, or warn |
Warning |
Logging level when a function fails to perform its intended task. |
2, or informational, or information, or info |
Informational |
Logging level when a function operates normally. |
1, or verbose, or debug |
Verbose |
Logging level for detailed troubleshooting scenarios. |
Then, log messages will be printed to console (stderr).
Note that stderr messages can be redirected into a log file like this:
On Windows:
myprogram.exe 2> log.txt
On Linux or macOS:
./myprogram 2> log.txt
In addition, log messages can be programmatically processed by providing a callback function, which can save them to a file, or display them in a desired custom way.
#include <azure/core/diagnostics/logger.hpp>
int main()
{
using namespace Azure::Core::Diagnostics;
// See above for the level descriptions.
Logger::SetLevel(Logger::Level::Verbose);
// SetListener accepts std::function<>, which can be either lambda or a function pointer.
Logger::SetListener([&](auto lvl, auto msg){ /* handle Logger::Level lvl and std::string msg */ });
}
Note, the listener callback is executed on the same thread as the operation that triggered the log message. It is recommended implementation due the minimal amount of log message processing on the callback thread. Where message processing is required, consider implementing in a way that the callback pushes the message string into a thread-safe queue, so that another thread would pick the messages from that queue and handle them.
Next steps
Explore and install available Azure SDK libraries.
Contributing
For details on contributing to this repository, see the contributing guide.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit the Contributor License Agreement.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
Additional Helpful Links for Contributors
Many people all over the world have helped make this project better. You'll want to check out:
- What are some good first issues for new contributors to the repo?
- How to build and test your change
- How you can make a change happen!
- Frequently Asked Questions (FAQ) and Conceptual Topics in the detailed Azure SDK for C++ wiki.
Reporting security issues and security bugs
Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) secure@microsoft.com. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the Security TechCenter.
License
Azure SDK for C++ is licensed under the MIT license.