Default for SNC when using SAP Logon

[tim_alsop]

When using SNC authentication in SAP Logon 6.40, currently it is necessary to add all of the details to saplogon.ini file, e.g.

[SncName]

Item1=p:sapnsp/unix1.domain.com@DOMAIN.COM

Item2=p:sapnw4/unix2.domain.com@DOMAIN.COM

[SncChoice]

Item1=9

Item2=9

In order to avoid having to maintain the saplogon.ini, we have found we can use logon groups to logon to the systems. However, when a group logon is used, it seems that SAP Logon is not aware of the need to use SNC authentication, so a userid+password logon screen appears. To inform SAP Logon that we want to use SNC, we need to use the "Add and Log on" button in SAP Logon "Group Selection", which then allows us to edit the entry added, and enable SNC.

If it was possible to configure SAP Logon so that a default SncChoice was used, then it would not be necessary to use the "Add and Log on" button and then edit the entry each time. Instead, we could just allow the user to press the "Generate List" button and then select the group name, and press "Log on" button to logon via SNC.

Is there was a way to configure SAP Logon or SAP GUI to use a default value for SncChoice, instead of requiring this to be present in the saplogon.ini file. I wondered if there was/is an environment variable, or a way to configure a default SncChoice value, in case a value is not found in saplogon.ini during logon.

I appreciate that most customers of SAP use a central saplogon.ini which they add entries to, and we are considering this option as well, but wondered if there was an alternative approach using the logon groups, as described above.

If you have any useful suggestions or comments, or information about configuring a default SncChoice value I would be pleased to hear from you.

[WolfgangJanzen]

Hi Tim,

I like your idea - and I would use that feature ("SNC option enabled by default") gladly if it would be offered. But this is a classical "feature request" - which you'd have to send to the right target group: the SAPGUI development group (SAP customer message component BC-FES-GUI).

Cheers, Wolfgang

PS: I'm also surprised to see that SAPGUI itself creates SAPshortcut files (when pressing the button which is offered when using an open SAPGUI session) which do not have the SNC option enabled although the SAPGUI session is SNC-enabled.

[tim_alsop]

Wolfgang,

Thankyou for confirming this is not currently available. I was not sure.

I will get the customer who asked me about this to open an enhancement, because I guess enhancements are considered more important if a customer of SAP opens them rather than a partner such as ourselves.

I also wondered if there was anything in SAP GUI 7.10 (due Feb 5th) that might help ... Do you know ?

Regards,

Tim

[WolfgangJanzen]

Tim, you seem to be well-informed - regarding SAP GUI 7.10 you know more than me (honestly).

Regards, Wolfgang

[tim_alsop]

Wolfgang,

I have awarded points. Thankyou for your help.

The customer who asked me about this seems happy to use saplogon.ini and maintain the SNC enable/disable flags in this file, just like most customers are doing already. I have asked them to open an enhancement request if they consider the change to be of interest in the future.

Regards,

Tim

[WolfgangJanzen]

Well, there are other features that "SAP GUI for Windows" currently does not offer but that sometimes are requested (by individual customers):

- ability to store the <b>client</b> setting (to denote the "logical system") in the SAPLOGON entry

- ability to store the <b>language</b> setting in the SAPLOGON entry

Together with the request to enable the "SNC option" by default (when creating new SAPLOGON entries) that would be a good proposal.

Well, who wants to submit it to SAP ...?

Are those enhancements really requested by a reasonable number of customers? Or are those just considered "nice to have" features - which everybody would take if they are offered but nobody wants to take the initiative to request them ...?

Just my 5 cents.

Regards, Wolfgang

[tim_alsop]

> Well, who wants to submit it to SAP ...?

> Are those enhancements really requested by a

> reasonable number of customers? Or are those just

> considered "nice to have" features - which everybody

> would take if they are offered but nobody wants to

> take the initiative to request them ...?

>

> Just my 5 cents.

> Regards, Wolfgang

I think you are correct, that these are the kind of enhancement that are not considered big enough to justify spending the time making the request to SAP. Also, I hope you don't mind me saying this, but I think customers have a low(ish) level of confidence in SAP being able to enhance the product in a meaningful timeframe when they make requests, so they prefer not to bother :-).

Perhaps, for small enhancements like this there is a procedure inside SAP, where people such as yourself can request that changes are made ? In our company, many small enhancements are made which only take a few days work, including testing, and are based on feedback provided to our development team from field/support resources, such as myself.

Thanks,

Tim

[WolfgangJanzen]

> Also, I hope you don't mind me saying this, but I

> think customers have a low(ish) level of confidence

> in SAP being able to enhance the product in a

> meaningful timeframe when they make requests, so they

> prefer not to bother :-).

Well, I can understand that such an impression can result if requests for (sometimes fairly small) enhancements take long time or are implemented only in newer releases. But: some of those enhancements lead to downwards-incompatible changes. Or, taking into consideration that every change bears a certain risk of instability, such an enhancements need to be carefully thought of .- and tested accordingly.

Some feature requests sound like "small effort" (and indeed are "fast to hack") but might cause problems in future and then need to be deprecated. In that case, it's better to invest in a proper solution - which, however, also takes more time for design and implementation, testing, documenting, ... (because it's more powerful).

Keep in mind: modifications in the kernel / ABAP core effect many thousand customers.

> Perhaps, for small enhancements like this there is a

> procedure inside SAP, where people such as yourself

> can request that changes are made ?

Only if that enhancement is really very small - and if it effects only one single (tiny) component. If the impact is not limited or if multiple development teams need to get involved, such changes require a proper planning.

> In our company, many small enhancements are

> made which only take a few days work, including

> testing, and are based on feedback provided to our

> development team from field/support resources,

> such as myself.

Well, how many customers are effected by such enhancements?

If something goes wrong, how serious is their business effected?

I hope you understand what I'm trying to say.

It makes a huge difference, if an onsite consultant performs a modification (in a single customer system, knowing the concrete constraints of that environment) or whether a developer changes a component which is shipped to many thousands customers (and which is supposed to work in all environments which are officially supported).

Regards, Wolfgang

-

---

Disclaimer: The above statements express my private opinion.

[tim_alsop]

Wolfgang,

Yes, I fully understand what is needed to ensure stability and quality of any change or enhancement, regardless of how small the change is. This was not under dispute, but maybe you misunderstood what I was suggesting ?

In our company, when somebody in support/field etc. finds a change which they think will be useful to improve the product in some way, or help a customer or prospect they have been talking with - this person logs a description of the proposed change on our internal tracking system, and the development team are then asked to take a look, providing feedback etc.. The development team then take a view on current roadmap, expected time to make the change, amount of testing required, impact on existing customers, before they schedule time to make the change requested. Sometimes they indicate that the change cannot be made easily or quickly, and they specify whether it can be retro fitted to existing releases, or whether it will be included in the next service release, etc. Of course I am simplyfying this process, and missing out some details, but hopefully it is better than my previous explanation, thus avoiding any misunderstandings ?

I hope this wraps up any misunderstandings. Clearly the larger the number of customers, and larger the development team the more time this process takes. I fully understand and appreciate this, and this is why it is often the case that SAP take a long time to make changes requested by customers.

Take care,

Tim

[WolfgangJanzen]

Well, we used to have that ability (to submit "internal development requests" and "development requests on behalf of a customer") previously. But it turned out, that you need quite some effort to look through them - in order to detect duplicates / similiar requests and in order to judge on their importance / business need.

That's why a more formalized (and more restrictive) process was set up.

Well, maybe too formalized (and restrictive) ...

Personally, I'm with you: the field staff has a valuable knowledge on the customers' needs. That information should flow back to development. Well, the hard part is the pre-scanning (filtering and grouping) followed by the actual evaluation / judgement (requiring some technical knowledge as well as a sense for business needs).

Well, you also indicate that such a process can be quite complex. Complexity of that process will definetly increase with the complexity of the product (due to increased number of side-effects, constraints, impacts, etc.).

Hmmm - if I'd know the perfect solution for that problem (to satisfy the needs of all persons involved) I could become rich ...

Good night,

Wolfgang