Release 5.0 (Beta 2)

What's Changed

• Bump xunit.runner.visualstudio from 2.5.7 to 2.8.1 by @dependabot in #297
• Bump xunit from 2.8.1 to 2.9.1 by @dependabot in #308
• Bump JetBrains.Annotations from 2023.3.0 to 2024.2.0 by @dependabot in #299
• Bump Microsoft.NET.Test.Sdk and Newtonsoft.Json by @dependabot in #307
• Fixed mapping of the optional parameters when getting the parameters description from SAP SDK by @ipezkine-ext in #315
• Allow direct access to connection and datacontainer handles by @fw2568 in #317

New Contributors

• @ipezkine-ext made their first contribution in #315

Full Changelog: v5.0-beta.1...v5.0-beta.2

Release 4.3.5

What's Changed

• Fixed mapping of the optional parameters when getting the parameters description from SAP SDK by @ipezkine-ext in #315, downported in #316

New Contributors

• @ipezkine-ext made their first contribution in #315

Full Changelog: v4.3.4...v4.3.5

Release 5.0 (Beta 1)

Breaking changes

Removed AllowStartOfPrograms from IRfcRuntime and IConnection

AllowStartOfPrograms was marked as obsolete in the previous release and has been removed.

RfcErrorInfo replaced by RfcError

Within language-ext the logic of error types (e.g. used in Either,L,R) has changed from a struct (like RfcErrorInfo) to a class hierarchy starting with the error type Error. Therefore, we have replaced RfcErrorInfo with the new type RfcError in all APIs.
RfcError is syntactically compatible with RfcErrorInfo and it can be converted between the two types. So you can simply replace RfcErrorInfo with RfcError in all your code.

Deprecation of RfcRuntime

The RfcRuntime was the central class to abstract between the Netweaver SDK API and YaNco. Originally YaNco was built with several runtime versions (either a managed C++ implementation or an Interopt version). These days the RfcRuntime is only used for unit testing, but is quite difficult to handle.
The RfcRuntime is no longer used internally. Instead, we now use the language-ext runtime concept (see also https://github.com/louthy/language-ext/wiki/How-to-deal-with-side-effects). This abstracts between all operations that perform IO (calls to SAP Netweaver RFC SDK) and our library.

The default runtime we use is SAPRfcRuntime which is a struct that provides access to IO effects (e.g. RfcConnectionEff). However all types have been updated to support also a custom runtime that users build for their applications (for example a runtime with Console support).

For example, RfcContext is now also available as RfcContext<RT>, where RT is the type of runtime to use. All new types also no longer use EitherAsync<RfcError,R>, but Aff<RT, R> (or the synchronous version Eff<RT,R>). Aff is the type of an asynchronous effect that is not executed immediately, but only in the context of a runtime.

Also the ConnectionBuilder and RfcServerBuilder are now implemented as generic type ConnectionBuilder<RT> and RfcServerBuilder<RT>. If you use the generic version, you opt for the new runtime concept, so the Build() methods of both builders will now return an Aff<RT, R> instead of a Func<Either<RfcError,R>.

The non generic versions of these types are still available. So common use cases should work without any change.
But if you have used deeper APIs, you will have some types where you may need to add the runtime generic type parameter to your code.

You will also have to rewrite all unit tests that replaced calls on IRfcRuntime with mocked IO effects. See our unit tests for an example.

Connection was replaced by Connection<RT>

The non-generic version of Connection was removed.
This will typically only be noticed during unit testing, as you don't normally need to create the connection yourself.

ConnectionBuilder runtime methods results change

If you have configured a runtime using the ConfigureRuntime method, you may notice that the result types within the builder have changed. The updated version of ConfigureRuntime no longer configures an IRfcRuntime, but the settings within the build-in SAPRfcRuntime.
If you used method UseFactory to inject another runtime factory you have to change it to UseSettingsFactory and to change the factory result from IRfcRuntime to SAPRfcRuntimeSettings.

Rfc Servers and callbacks are only supported with runtime type

For callbacks and RFC servers, we have removed support for the non-generic versions, as adding them would have required a lot of duplicate code. Since RFC servers are also a more expert feature, we feel that this change will not have a big impact.

This applies to to following types: CalledFunction, IRfcServer, RfcServer, RfcServerContext, ITransactionalRfcHandler
The context within a called function is also only available as IRfcContext, but this is consistent with the following change.

Function handlers now have to return effects (Eff or Aff)

In older versions function handlers had to return EitherAsync<RfcError,Unit>. This was changed to Aff<RT,Unit>. Also the Process method on a CalledFunction<RT> processing chain now has to return a Eff or Aff. ProcessAsync is still supported and will be wrapped into a Aff internally.

This change also removes an inconsistency in how errors are handled after the Process step of the function chain.
The Reply method of the called function chain no longer allows you to access the error of the process step if you return an Either. Instead, the error is always returned to the ABAP backend and Reply is not called.

Transactional RfcHandlers have to return Eff<RT,RfcRc>

Transactional handlers now have to return a effect (Eff). All unhandeled errors that occur in a transactional rfc handler will be logged and responded back to the SAP backend with RfcRc.RFC_EXTERNAL_FAILURE.

New features

Side-effect free functional API

As explained above, one of the key improvements in moving to the new runtime concept was the isolation of I/O operations.
Therefore, we now provide a new API that can be used to create pure functional code.

Please see the README for a high-level introduction to these patterns.
Typically, there is a learning curve to fully understand the concept of the new runtime, but once mastered, it allows you to write pure functional code like this: https://github.com/dbosoft/YaNco/blob/main/samples/net6.0/ExportMATMAS

For classic OO integration (and dependency injection via a dependency container), the RfcContext is still available and supported.
However, under the hood it just wraps to the functional API as the RfcContext has an internal managed runtime behind it that is created on the fly.

New types SAPRfcRuntime and TestSAPRfcRuntime

The SAPRfcRuntime was allready explained in detail above. The TestSAPRfcRuntime should be used for unit testing, by setting its IO implementations to mock implementions. We have not added any mock types to the library as we assume that you use a mocking framework like Moq.

IO interfaces

The IRfcRuntime was splitted into following IO interfaces. Please note that we followed the naming convention of language-ext that IO interfaces don't start with an I.

• SAPRfcTypeIO
  Used for type creation and type information lookup

• SAPRfcStructureIO
  Used for SAP structure management

• SAPRfcTableIO
  Used for table management and navigation to table rows.

• SAPRfcFunctionIO
  IO operations for SAP functions like creation of function descriptions and invocation of functions.

• SAPRfcConnectionIO
  Used for deep level connection IO that are normally only executed within a IConnection.

• SAPRfcServerIO
  Used for deep level server IO that are normally only executed within a IRfcServer.

• SAPRfcFieldIO
  IO methods for mapping and reading of field values either directly from the NW RFC SDK or via a field mapper.

New class SAPRfc<RT>

The SAPRfc<RT> is a static class that implements a number of common use cases for interacting with SAP systems as a client. It is pure functional without any side-effects.
Highlighted methods:

• useConnection
  This method takes a Aff<RT,IConnection> as input (as from the ConnectionBuilder<RT>.Build method) and allows to use the IConnection with the provided function.
• useContext
  This method also takes a Aff<RT,IConnection> as input, but then provides a IRfcContext<RT> within the function. In this case the connection will be managed by the context.

Added extension method RunIO to IRfcContext

As IRfcRuntime is deprecated but IRfcContext is not, we have to provide a way that users can access IO effects from a RfcContext.
RunIO provides a bridge from IRfcContext to the new functional API. The effect constructed with this method will be run with the build-in SPRfcRuntime.

Internals

• Cleaned up code quality issues throughout the project.
• Updated sample ExportMATMAS to functional style.
• Dependencies have been updated to latested versions,
• Disabled security warnings for ASPNET Core 2.x as it is only used in samples.

Release 5.0 alpha.2

This release should only be consumed by those who are interested in the new features coming in the v5 release.

Not ready for production!

If you add it to a production project, you should only do so to see (potentially) how many breaking changes there are.

Breaking changes

see https://github.com/dbosoft/YaNco/releases/v5.0-alpha.1 for alpha.1 breaking changes

Transactional RfcHandlers have to return Eff<RT,RfcRc>

Transactional handlers now have to return a effect (Eff). All unhandeled errors that occur in a transactional rfc handler will be logged and responded back to the SAP backend with RfcRc.RFC_EXTERNAL_FAILURE.

Reduced number of traits

This is breaking only between alpha.1 and alpha.2:
Instead of using one trait per IO implementation we have reduced traits to HasSAPRfc<RT> for clients and HasSAPRfcServer<RT> for servers. This reduced the complexity for runtime type constraint.

New Features

Added extension method RunIO to IRfcContext

As IRfcRuntime is deprecated but IRfcContext is not, we have to provide a way that users can access IO effects from a RfcContext.
RunIO provides a bridge from IRfcContext to the new functional API. The effect constructed with this method will be run with the build-in SPRfcRuntime.

Internals

• Cleaned up code quality issues throughout the project.
• Updated sample ExportMATMAS to functional style.
• Dependencies have been updated to latested versions,
• Disabled security warnings for ASPNET Core 2.x as it is only used in samples.

Release 5.0 alpha.1

This release should only be consumed by those who are interested in the new features coming in the v5 release.

Not ready for production!

If you add it to a production project, you should only do so to see (potentially) how many breaking changes there are.

Breaking changes

Removed AllowStartOfPrograms from IRfcRuntime and IConnection

AllowStartOfPrograms was marked as obsolete in the previous release and has been removed.

RfcErrorInfo replaced by RfcError

Within language-ext the logic of error types (e.g. used in Either,L,R) has changed from a struct (like RfcErrorInfo) to a class hierarchy starting with the error type Error. Therefore, we have replaced RfcErrorInfo with the new type RfcError in all APIs.
RfcError is syntactically compatible with RfcErrorInfo and it can be converted between the two types. So you can simply replace RfcErrorInfo with RfcError in all your code.

Deprecation of RfcRuntime

The RfcRuntime was the central class to abstract between the Netweaver SDK API and YaNco. Originally YaNco was built with several runtime versions (either a managed C++ implementation or an Interopt version). These days the RfcRuntime is only used for unit testing, but is quite difficult to handle.
The RfcRuntime is no longer used internally. Instead, we now use the language-ext runtime concept (see also https://github.com/louthy/language-ext/wiki/How-to-deal-with-side-effects). This abstracts between all operations that perform IO (calls to SAP Netweaver RFC SDK) and our library.

The default runtime we use is SAPRfcRuntime which is a struct that provides access to IO effects (e.g. RfcConnectionEff). However all types have been updated to support also a custom runtime that users build for their applications (for example a runtime with Console support).

For example, RfcContext is now also available as RfcContext<RT>, where RT is the type of runtime to use. All new types also no longer use EitherAsync<RfcError,R>, but Aff<RT, R> (or the synchronous version Eff<RT,R>). Aff is the type of an asynchronous effect that is not executed immediately, but only in the context of a runtime.

Also the ConnectionBuilder and RfcServerBuilder are now implemented as generic type ConnectionBuilder<RT> and RfcServerBuilder<RT>. If you use the generic version, you opt for the new runtime concept, so the Build() methods of both builders will now return an Aff<RT, R> instead of a Func<Either<RfcError,R>.

The non generic versions of these types are still available. So common use cases should work without any change.
But if you have used deeper APIs, you will have some types where you may need to add the runtime generic type parameter to your code.

You will also have to rewrite all unit tests that replaced calls on IRfcRuntime with mocked IO effects. See our unit tests for an example.

Connection was replaced by Connection<RT>

The non-generic version of Connection was removed.
This will typically only be noticed during unit testing, as you don't normally need to create the connection yourself.

ConnectionBuilder runtime methods results change

If you have configured a runtime using the ConfigureRuntime method, you may notice that the result types within the builder have changed. The updated version of ConfigureRuntime no longer configures an IRfcRuntime, but the settings within the build-in SAPRfcRuntime.
If you used method UseFactory to inject another runtime factory you have to change it to UseSettingsFactory and to change the factory result from IRfcRuntime to SAPRfcRuntimeSettings.

Rfc Servers and callbacks are only supported with runtime type

For callbacks and RFC servers, we have removed support for the non-generic versions, as adding them would have required a lot of duplicate code. Since RFC servers are also a more expert feature, we feel that this change will not have a big impact.

This applies to to following types: CalledFunction, IRfcServer, RfcServer, RfcServerContext, ITransactionalRfcHandler
The context within a called function is also only available as IRfcContext, but this is consistent with the following change.

Function handlers now have to return effects (Eff or Aff)

In older versions function handlers had to return EitherAsync<RfcError,Unit>. This was changed to Aff<RT,Unit>. Also the Process method on a CalledFunction<RT> processing chain now has to return a Eff or Aff. ProcessAsync is still supported and will be wrapped into a Aff internally.

This change also removes an inconsistency in how errors are handled after the Process step of the function chain.
The Reply method of the called function chain no longer allows you to access the error of the process step if you return an Either. Instead, the error is always returned to the ABAP backend and Reply is not called.

New features

Side-effect free functional API

As explained above, one of the key improvements in moving to the new runtime concept was the isolation of I/O operations.
Therefore, we now provide a new API that can be used to create pure functional code.

Please see the README for a high-level introduction to these patterns.
Typically, there is a learning curve to fully understand the concept of the new runtime, but once mastered, it allows you to write pure functional code like this: https://github.com/dbosoft/YaNco/blob/main/samples/net6.0/ExportMATMAS

For classic OO integration (and dependency injection via a dependency container), the RfcContext is still available and supported.
However, under the hood it just wraps to the functional API as the RfcContext has an internal managed runtime behind it that is created on the fly.

New types SAPRfcRuntime and TestSAPRfcRuntime

The SAPRfcRuntime was allready explained in detail above. The TestSAPRfcRuntime should be used for unit testing, by setting its IO implementations to mock implementions. We have not added any mock types to the library as we assume that you use a mocking framework like Moq.

IO interfaces

The IRfcRuntime was splitted into following IO interfaces. Please note that we followed the naming convention of language-ext that IO interfaces don't start with an I.

• SAPRfcTypeIO
  Used for type creation and type information lookup

• SAPRfcStructureIO
  Used for SAP structure management

• SAPRfcTableIO
  Used for table management and navigation to table rows.

• SAPRfcFunctionIO
  IO operations for SAP functions like creation of function descriptions and invocation of functions.

• SAPRfcConnectionIO
  Used for deep level connection IO that are normally only executed within a IConnection.

• SAPRfcServerIO
  Used for deep level server IO that are normally only executed within a IRfcServer.

• SAPRfcFieldIO
  IO methods for mapping and reading of field values either directly from the NW RFC SDK or via a field mapper.

New class SAPRfc<RT>

The SAPRfc<RT> is a static class that implements a number of common use cases for interacting with SAP systems as a client. It is pure functional without any side-effects.
Highlighted methods:

• useConnection
  This method takes a Aff<RT,IConnection> as input (as from the ConnectionBuilder<RT>.Build method) and allows to use the IConnection with the provided function.
• useContext
  This method also takes a Aff<RT,IConnection> as input, but then provides a IRfcContext<RT> within the function. In this case the connection will be managed by the context.

Release 4.3.4

What's Changed

• Bug fix: CachingConverterResolver concurrency by @fw2568 in #282

Full Changelog: v4.3.3...v4.3.4

v4.3.3

What's Changed

• Make TableHandle implement IDataContainerHandle (fixes #260) by @prodehghan in #261

New Contributors

• @prodehghan made their first contribution in #261

Full Changelog: v4.3.2...v4.3.3

v4.3.2

Bug fixes:

Create runtime only once per ConnectionBuilder by @fw2568 in #243

Full Changelog: v4.3.1...v4.3.2

Release 4.3.1

Bug fixes:

Don't throw InvalidOperationException by @fw2568 in #234

Release 4.3

⭐ New Features

• Rfc Server by @fw2568 in #205
• Improved RFC Server by @fw2568 in #218
• Generic client callback registration by @fw2568 in #204

🚀 Improvements

• Convert structures and tables to AbapValue by @fw2568 in #195
• Get connection attributes by @fw2568 in #198
• Uppercase fields, parameter and options by @fw2568 in #186

🏃 Internals

• Bump GitVersion.MsBuild from 5.10.1 to 5.10.3 by @dependabot in #174
• Bump Microsoft.NET.Test.Sdk from 17.1.0 to 17.2.0 by @dependabot in #170
• Bump xunit.runner.visualstudio from 2.4.3 to 2.4.5 by @dependabot in #169
• Bump System.CommandLine.Hosting from 0.4.0-alpha.22114.1 to 0.4.0-alpha.22272.1 by @dependabot in #180
• Bump coverlet.collector from 3.1.2 to 3.2.0 by @dependabot in #192
• Bump Microsoft.NET.Test.Sdk from 17.2.0 to 17.3.2 by @dependabot in #191
• Bump CompareNETObjects from 4.76.0 to 4.78.0 by @dependabot in #190
• Bump xunit from 2.4.1 to 2.4.2 by @dependabot in #187
• Bump GitVersion.MsBuild from 5.10.3 to 5.11.0 by @dependabot in #201
• Bump Microsoft.NET.Test.Sdk from 17.3.2 to 17.4.0 by @dependabot in #199
• Bump GitVersion.MsBuild from 5.11.0 to 5.11.1 by @dependabot in #207
• Bump JetBrains.Annotations from 2022.1.0 to 2022.3.1 by @dependabot in #206
• Bump GitVersion.MsBuild from 5.11.1 to 5.12.0 by @dependabot in #214
• Bump Microsoft.NET.Test.Sdk from 17.4.0 to 17.5.0 by @dependabot in #216
• Bump Newtonsoft.Json from 13.0.1 to 13.0.2 by @dependabot in #211

Full Changelog: v4.2.1...v4.3