SAP .NET Connector and VS2005 on MS's Channel9

[Former Member]

Loot at it and enjoy....

http://channel9.msdn.com/Showpost.aspx?postid=172150

Greetings

Henning

[darren_martin · Accepted solution]

I thought this video gave some good insight into how Microsoft and SAP work together to deliver a toolset.

Now if we could just get SAP to listen to us and give us more of what we want and not what they think we want; life would be sweet.

Just to give you an example of what I mean...I started working on a replacement project for ESS completely written using asp.net and .net connector. I initially started the project wanting to use PDK but quickly found that it just wasn't there yet. The controls were weak...layout sucked, but the integration to the portal was great. Weak controls mean a lame end product. I quickly changed gears and went with developing the pages on IIS using mysapsso2 (wrapper), .net connector and a rich control set; end result was a nice looking and well functioning product that integrated fairly well into the portal environment.

What I also like about .net and the .net connector is that I can write a winform and webform application using basically the same code. Which means that we can develop a repository of reusable code to help us develop excellent looking/functioning interfaces into SAP..quicker.

SAP should focus more on working with Microsoft then trying to go a completely different way. Let’s face the facts...the majority of SAP installations run on Windows, most everyone uses Microsoft Office Tools to present the data from SAP and finally most small IT shops use Visual Studio to develop applications and run IIS as a web server.

So how is it that SAP went j2ee? Politics?

Am I the only person with this opinion?

[Former Member · Accepted solution]

Hi Darren,

Being a "mere" SAP employee and not a executive, I can't answer your "SAP-policy" questions... but I did feel compelled to comment on your post (regarding the PDK).

1. I can understand that maybe you didn't like the offered control set or its features, it's a matter of opinion (see question 4) - but I still don't understand why you didn't use the PDK with your own set of controls... why use IIS? why maintain a double web server in one organization? Also, If you like using the .NET connector, it's well integrated with the PDK and the portal (can use the portal cookies, the system landscape, user mapping etc'), and would have saved you some connection issues and administration of landscape in a config file (or separate database).

2. while I'm wondering - how is the performance and maintainability of your chosen solution? do you have IIS clustering (which as far as I know means just re-deploying your content to lots and lots of nodes?)

When using the PDK, you enjoy the portal's strong and inherent clustering capabilities and also can cluster the .NET run-time nodes if needed. and also since all configurations are done via the portal administration (single point).

3. And how did you maintain a single look and feel with other portal apps with your own control set? did you support more than one theme in this solution? As you probably know, the PDK's "weak" control-set is completely SAP-UI compliant and supports the portal's themes.

4. and while your at it... when did you did the controls evaluation? the control set has expanded greatly over the last 3 versions and now contains all the "standard" SAP controls.

5. One last thing - what did you by mean by "layout sucked"? I just don't understand since the layout is that of any regular ASP.NET app.. (or do you usually use the highly-unrecommended-by-MS "fixed" layout?)

Oh, I know these are mostly rhetorical questions (which I've answered myself, so you don't have to)...

I just couldn't help it

Regards,

Ofer

[Former Member · Accepted solution]

Hello Darren

I have also the same opinion, in my case we also are developing ASP.net 2.0 applications on IIS and using mysapsso2. Why? because WebDynpro is complex, slow and dificult to maintain, is faster to develop with VStudio 2005, and we created skin files to have the same look and feel of a portal application.

We have the SAPPortal Installed on SUN Cluster, and let me tell you that doesn't work fine, we can't upgrade from SP09, and this version has memory problems with J2EE, every week the portal goes down and we have to restart the services, and my IIS server is running without problems.

[darren_martin · Accepted solution]

Ofer,

You made some valid points but I think they are more relevant to a large company with lots of resources. In our organization we have 3 people who support SAP. I am the basis admin, abap developer, integration developer and DBA....plus do my "other" job DBA, manager and senior application developer. We installed R/3 ourselves, upgraded R/3 3 times ourselves, did a platform migration ourselves (just need a guy from HP to use his certification #), support R/3 and now have just implemented portal.

To answer your questions.....

1. IIS is far easier to maintain is and far more stable (no clustering). Sure .NET connector is integrated well with PDK and I mentioned that in my orginal post. But 2.0 supports sso ticket so my method is just a good and is simple to maintain because you only have to change the config in the web.config file to move it between QA and Prod.

2. Rock solid and extremely fast.

3. Style Sheets. From what I understand is how portal maintains a common look and feel.

4. And this is a good thing? SAP does not know how to make anything look "sexy"; have you ever used the GUI.

5. There is no absolute positioning of controls. You have to use tables to do your layout....so 1995.

My biggest problem with portal is that SAP threw out all the methodology they implemented in R/3...i.e. version control, a real transport system, etc. It just seems so infantile.

My original comment stands...they could learn a lot from Microsoft. Implement the 4 minute rule. Which is if you give the product to a user they should be able to be productive within 4 minutes or it goes back to development.

Regards,

Darren

[Former Member]

On the same lines, Can somebody help me in identifying steps of how to use the proxies generatd in VS 2003 in VS2005.

When i drop all the wsdl and .vb files related to a proxy from VS2003 to my project folder in VS2005. It gives me error saying reference not found eg: SAPStructure not defined.

[reiner_hille-doering]

Please reference SAP.Connector.DLL and SAP.Connector.Rfc.DLL assemblies in your VS 2005 project.

[darren_martin]

I just want to add that it may appear that I am bashing SAP, but in reality I am just trying to state some facts. I really hope that someone from SAP reads my comments and takes them seriously; perhaps it will bring about some positive changes.

[Former Member]

Upppssss. Sorry for this mistake....

BTW.. i find the headline very very funny "Vijay Rajagopalan - SAP converts to Visual Studio 2005".

And the following text :

"Recently he, and the team he works with, was on campus (all the way from Israel) to port SAP (famous software!) to Visual Studio 2005.".

Greetings

Henning

[Former Member]

Henning Bach,

This might interest you...

What they (SAP) will not do is to make the .Net connector design time work in VS2005. This is consistent with the message that they would like to switch to a services based architecture. If you have WebAS installed or ECC you may use the WSDL to create a proxy and make the web service call. Alternatively, you can use proxies created using the .Net connector in VS2003. The run time will work just fine. It is the design time environment they will not be moving forward. Finally, you may also choose to use the .Net provider that Microsoft has. The nice thing about this solution is that it makes SAP appear as a data source. It is very nice I think.

The impact is that if you want to use the .Net connector then you have to create the proxy in VS2003, and then include the file in VS2005 project. .Net iViews are only webparts in SharePoint®. The architecture is such that the actual assembly is loaded wherever the SAP .Net runtime is. This runtime is a wrapper around the .Net runtime and provides authentication and some other services such as caching and retrieval of the iView from the repository.

I can’t speak for the PDK. However, the projects that the PDK uses require two things to be loaded in VS2005. The first is a GDR which will be available at the end of April. The second is a patch that will be available simultaneously. These two things together provide the basis for some very cool features in VS2005 and the PDK that were not previously available. One of these is the web project which was present in VS2003, but disappeared in VS2005. It is back by popular demand!

SAP has announced that they will be releasing version 2.5 of the PDK. This runs beautifully on VS2005. They have deprecated version 2.0 running on VS2003, but will continue to support it through the normal life cycle. There are several new features of the 2.5 version that make it worth using. Among these features are the use of both SAP and MSFT controls inside of the environment and SharePoint®.

Look for the PDK 2.5 end of April.

You can also watch presentation on

http://channel9.msdn.com/Showpost.aspx?postid=172150

James

[Former Member]

We have been using .NET connector in visual studio 2003, to call bapis and other remote function modules from .net. I read, that .net connector would not work in Visual Studio 2005, we would still have to create proxies in VS2003. Is there any other way to work around that, to call bapis from VS2005, not having to go back to VS2003. Has SAP come out with a date , when it will be going to be available ....

[Former Member]

Tarun,

Proxies are required for VS2003. PDK 2.5 should be out in April.

James

[Former Member]

Thanks James,

PDK 2.5 still wont support creation of proxies in VS2005. is that correct?

In order to call bapis/rfc's from .net vs 2005 , what would be the easiest way...

[reiner_hille-doering]

> In order to call bapis/rfc's from .net vs 2005 ,

> what would be the easiest way...

Use Web Services:

- In WAS 6.20 use the generic Soap Processor.

- In WAS 6.40 and higher: Use the Web Service Wizard.

- In ERP 2004 and 2005: Use ESA Services.

[Former Member]

That is correct, at this point in time that is the case. Use Web Services.

James

[Former Member]

Could you suggest me an article or an example, on how to do the web-service in order to call BAPIS in SAP. Do I have to install anything. In VS2003, i installed the .net connector to create proxies to call bapis/rfcs.

In vs 2005, what all should be installed in order to call bapis/rfc thru the web-service.

Reiner, you mentioned generic soap processor/ web serice wizard, so where do i get access to these.???

[reiner_hille-doering]

The good thing in WebServices is that you don't need anything on .NET side - everything is already contained in Visual Studio. The steps you have to do are on server side.

-For the Soap Processor, you usually only need to find the correct URL for WSDL. See http://service.sap.com/connectors -> Soap Processor for details.

- For the NetWeaver 2004 / 2004s you should use the WebService Wizard to expose a BAPI to WebServices. It runs in SAPGUI. See http://help.sap.com/saphelp_nw04/helpdata/en/0d/2eac5a56d7e345853fe9c935954ff1/frameset.htm for details.

- The best solution is using the official ESA Services. As soon as they become available you should be able to browse them from a UDDI or ESR directory. Details will be published on SDN.

[Former Member]

Just to clarify - It's about the porting of "PDK for .NET" (not .NET connector) to VS2005.

Regards,

Ofer