Writing .NET to access SAP that runs OUTSIDE a portal

[Former Member]

Wondering if anyone has had any experience writing application OUTSIDE of a portal environment that accesses SAP data.

Here is the scenario. I am writing an application in .NET that needs to accesses data in our SAP CRM environment as well as hook into the portal authentication / authorization. The data will be stored both in the standard data structures that comes with CRM as well as Z-Tables.

The thing is, the business really hasn't decided yet whether to run this application through the EP6 portal or as a stand alone web application. Ideally they want to defer this decision till later. As a result, I am trying to figure out a way to write the app so that it will work either way.

ie. initially run outside the portal and only bring up the login screen when a user clicks on a link from our public web site. Once authenticated through the portal the app would run on it's own outside of any kind of iView. 'Under the hood' it would connect to CRM using the credentials that it received during login.

Then once they decide (someday) to put this app in the portal it could be brough in as an iview and run there with little or no effort.

Quite a strange situation, but it comes about because of some of restrictions of running within the portal iViews.

I have been checking out the PDK V2.5 for the past week and so far it looks like this add-on requires the appilication to run within the portal. Correct?

Is there any way I can use the PDK to link into the portal authentication and authorization mechanism as well as CRM business objects WITHOUT running inside the portal environment? Is something like this even practical?

Many thanks for any ideas you might have.

-Sheldon

[Andre_Fischer]

If want to hook your ASP.NET page into the portal using an AppIntegration iView you have to distiguish two cases regarding authentication.

Option 1:

If we are talking about an Intranet scenario you would be able to use windows integrated authentication for your ASP.NET application.

Option 2:

If we are talking about an extranet scenario the following scenario might be useful

<a href="http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/4f209cf3-0201-0010-1db5-d2e33048b6c8">Using SAP Logon Tickets for Single Sign on to Microsoft based web applications</a>

Best regards,

André

[pratik_gandhi3]

Hello Andre,

I need you help in below query.

If we do not have SAP Portal and want to connect "SAP CRM" system to "ASP .NET applications" - what is the best way?

a. Is it connecting ASP .NET application to SAP CRM via SAP PI using Web services?

b. Is it connecting ASP .NET application directly to SAP CRM via RFC without SAP PI?

c. Is it connection ASP .NET application directly to SAP CRM via Web Services without SAP PI?

d. Or is there any better way?

We do not have any other third party system which can use SAP PI. Also there will 1 million users connect to ASP .NET application.

Thanks & Regards,

Pratik

[Andre_Fischer]

Hi Sheldon,

the easiest way would be to develop a ASP.NET application.

An ASP.NET application can either run standalone or as any Web application can easily be integrated into the SAP NetWeaver Portal using an Application Integrator iView. See for example my whitepaper<a href="http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/dc92ad90-0201-0010-3683-f24803caeb52">Integration of Outlook Web Access into SAP Enterprise Portal</a>

Your .NET application does not necessarly need to use the SAP connector for Microsoft .NET to access your SAP CRM system. Any remote enabled function module can be ´published as a web reference and thus easily be called from your application. See my blogs

Best regards,

André

[Former Member]

using the .NET Connector 2.0 as well as incorporating the .NET program into the landscape of the portal for access to UME

[Former Member]

Hello Sheldon,

You can simply add an SAP Connector Proxy to any .net application irrelevant to where is runns. I have sucessfully done this a number of times. The only difference is that you will need to define the destination properties rather than taking them from the portal. You could just add these to a web.config and then reference them in the code.

Hope this helps,

Paul.