Issues with SAP Nco 3.0 - RfcInvalidStateException

[Former Member]

Hello,

at a customer i started to get RfcInvalidStateException and i am unable to connect to the customers SAP System. The message in full detail is:

Exception ocurred: SAP.Middleware.Connector.RfcInvalidStateException: Cannot get a client connection: invalid destination IRIS (REPLACED)

   at SAP.Middleware.Connector.RfcDestination.GetClient(Boolean forRepository)

   at SAP.Middleware.Connector.RfcDestination.SetAttributeValues(RfcSystemAttributes attribs)

   at SAP.Middleware.Connector.RfcDestination.get_SystemAttributes()

   at SAP.Middleware.Connector.RfcRepository.AddDestination(RfcDestination dest)

   at SAP.Middleware.Connector.RfcRepository.GetRepositoryForDestination(RfcDestination destination)

   at SAP.Middleware.Connector.RfcDestination.get_Repository()

I am pretty unsure about the cause of the issue as all my connection parameters seem to be correct.

We build the connection on every execution by using this code:

public void Init()

        {

            _rfc = new RfcConfigParameters();

            _rfc.Add(RfcConfigParameters.AppServerHost, _connection.AppServerHost);

            _rfc.Add(RfcConfigParameters.SystemNumber, _connection.SystemNumber);

            _rfc.Add(RfcConfigParameters.User, _connection.User);

            _rfc.Add(RfcConfigParameters.Password, _connection.Password);

            _rfc.Add(RfcConfigParameters.Client, _connection.Client);

            _rfc.Add(RfcConfigParameters.SystemID, _connection.SystemID);

            _rfc.Add(RfcConfigParameters.Name, _connection.Name);

            _rfcDest = RfcDestinationManager.GetDestination(_rfc);

            RfcSessionManager.BeginContext(_rfcDest);

            _rfcRepo = _rfcDest.Repository;

            _initCalled = true;

        }

Anything we obviously do wrong when building the connection?

Is anything cached here internally in Nco 3.0?

Thanks for any ideas/hints!

Wolfgang

[MarkusTolksdorf · Accepted solution]

Hi Wolfgang,

The exception message means that there has been some other thread using the same destination (name), but with different properties. In this case the previous instance will be marked as invalid and can no longer be used. Please note that a destination is not a connection. It is a configuration object that could represent many connections that are associated with it via their matching properties.

Is it an option for you to not provide the destination configuration within the application code, but register an implementation of IDestinationConfiguration, which is taking care of looking up destinations in a storage for the configurations? The application can then simply use the destination and does not have to worry about this. The situation you are experiencing will then happen only, when keeping a rerference to an RfcDestination for re-use and an Administrator is changing the configuration of exactly this destination. Furthmore, I can see that you are setting the connection to stateful - is this really required?

Best regards,

Markus

[Former Member · Accepted solution]

Hello,

thanks for your answer. I have to admit as much as i like the new connector 3.0 i have issues to correctly understand the concept behind the RfcDestinationManager.

Ideally i would like to build just one ad-hoc connection, use it and free it again. Ideally this code would transparently use different connection settings whenever they have been changed in the meantime on each call. It seems that what i do now is not the correct way for this. Will your approach using a IDestinationConfiguration do what I need? How would that react in such a scenario? Would it recover automatically?

By the way, where did i configure it to be stateful (or do i have to disable this explicitly)? What impacts would a stateless connection have to my  code? What would i have to look out for where i could get issues when changing this?

Sorry for maybe some dumb questions, but my main scope of work is not SAP so i am not that deeply into the architecture of the SAP Connector especially for building up a connection to SAP it seems.

Thanks for any feedback,

Wolfgang

[MarkusTolksdorf · Accepted solution]

Hi Wolfgang,

both for NCo 3.0 and JCo 3.0 you don't deal with connections. They use a more abstract approach with the destinations that also separate the concerns of administrating such destinations and using them in code as a developer. You set the destination to stateful by invoking RfcSessionManager.BeginContext(). This is only required, if you need to execute several function modules in a single LUW, e.g when creating a salesorder with the corresponding BAPI followed by a BAPI_TRANSACTION_COMMIT. In particular, for read-only scenarios this is not required. When working stateless, the ABAP system can cleanup resources fast and re-use of connections is possible much better.

If you need to communicate to different system, you would use different destinations. If you only need to use different users, you can work with RfcCustomDestinations. You can search the forum how to use them, it has been asked quite regularly.

It might also be a good idea to read the following blog on NCo:

A Spotlight on the new .NET Connector 3.0

Best regards,

Maakrus