Can an ASP.NET developer find a place in SAP?

[Former Member]

Hi, colleagues,

Just curious to hear your opinions. It's well known that SAP does not make wide use of MS development technologies. Still, there is something called ".NET connector" and several discussions in forums. Still the scope of it is not really clear.

As I've always been MS developer, starting with C++ and now my beloved ASP.NET, I have natural wish not to throw that all away.

The difficulty of the situation is that I do want to find a place in SAP after my master thesis is done, but at the same time do not particularly dream of Java and ABAP. How do you think, this dilemma is solvable or not in principle and the solution lies only outside of SAP?

Would appreciate your comments.

[Former Member]

I know many people working on integrations of .NET and SAP....And they do such great app's -:)

The thing is...at least on Peru....That people complain about SAP's boring look...So, sometimes they decide to hire a .NET Developer to make a fancy app, connect it to SAP and play with the data....That way, users feel much more confortable with the environment -;)

I wish they same could apply to Ruby or PHP....As .NET is not an open source app and having the Microsoft backup, it's easier for companies to adopt it as a development tool....

I haven't use the .NET Connector yet....But about 3 years ago....I use the R.I.P DCom connector and connected VB 6.0 with SAP....It was nice -:)

Greetings,

Blag.

[Former Member]

Hi Andrey,

how are you doing ?

i've made a living [and a decent one] interfacing SAP & .NET systems since 2003

personally, i feel the .net tools development team is strong, the dev community [of which i have the honour to be a part of] is excelent

if you look at it from the perspective of how many installations of r3 , ecc are on windows, you will find an answer which says that the relationship between MS & SAP is definitely getting better, which makes sense to them financially

so the roll out of newer tools should be in the offing, and they will improve in time. duet is such an example.

the dev center is also a brilliant resource

https://www.sdn.sap.com/irj/sdn/developerareas/dotnet?rid=/webcontent/uuid/3ecbe347-0a01-0010-5897-d... [original link is broken]

i can definitely recommend that you could help in the need to bridge the gap, rather than picking a side

at the end of the day, the idea is to deliver value [in terms of delivery times, using available resources and a smile from the user / customer who's day u're making easier ]

as there is never a clear winner in java Vs .net, or within SAP : ABAP Vs java, [.net is not even in contention within a SAP conversation )] the answer will be closer to if you can find a need and figure out the best possible way to fill it within the limitations of the environment

the real question here then becomes : what value can you bring as a consultant / developer ? there are many problems which exist in any eco system, finding one, solving it and developing a niche is a decent & viable strategy

if u're toolset happens to be VS.NET and u're talking to a SAP system, i'd say there are lots of projects which will be present, the number will not compare to

the sheer volume of ABAP / java projects, but those are taken care of by their own passionate communities, and there will always value for asp.net skills when interfacing, esp in corporate intranets

so keep learning, and grab opportunities which allow you to leverage u're past experiences while building new skills at the same time )

with respect,

amit

[Former Member]

You will do fine as a .NET developer. I've worked on many large projects and used .NET solely as the development tool. If you have robust understanding of the underlying relational database structure. Your application will be as fast as and sometimes even surpass the performance of ABAP. Remember SAP is a database and a GUI and there is more then 1 way to access a database.

- Tom

.NET MCSD

[Former Member]

<i>...SAP is a database and a GUI...</i>

rofl. you made my day ))

[stephenjohannes]

Actually that statement is not really funny, since that is the mindset of anyone trying to get someone to use solution X over a SAP solution for a business problem.

If you look back in the dot com boom days, this mentality was causing lots of SAP loyal customers to build projects using other toolsets regardless of the SAP solution available. There was talk that you could even get rid of the whole ERP system because it was nothing more than this.

As far as a .NET developer in the SAP ecosystem it should be possible. There are plenty of companies who love SAP's ERP solution but despise the external integration offerings of SAP. Plenty have choosen to use another tool instead to handle those needs.

I would think with all the cooperation between SAP and MS on new offerings there should be plenty of opportunities if you are creative. The key point in mind is that not every SAP customer is going to embrace the full Netweaver stack and only run what's necessary to keep their ERP system humming.

Just my thought,

Stephen

[Former Member]

I think Anton was kidding there Stephen. If not then I'm not sure what to think about Anton sense of humor anymore. Everybody here knows "SAP is just a db and a ui" right? pretty hard to reconcile or believe for anybody who's been involved even a tiny bit with R/3...

[Former Member]

Hi Thomas (Jung) -

Your pasage here really "made my day":

<b>"There is creativity and challenges to be found in core business SAP development (personally I love the challenge of performance tuning a long running report. I'm the type of person that gets excited talking about shared memory object caches), but it will be of a different nature than the kind of heavy UI paradigm innovation that are in your examples."</b>

If SDN management agrees that the "Coffee Corner" can be used for preliminary conversations and spec development for SDN collaboration projects (no running code - just sample algorithms, code snippets and data snippets), I will be opening a thread on a generic module for recursive computation on ABAP itabs that are the equivalent of WDA/J "tree-tables".

To do such recursive computations, I personally prefer creating a hashed itab on the way down the original data tree (e.g. chasing ukalns from kalnrs in ckis), and then bouncing in and out of the itab to get parent data when you're on a child of the parent.

But you/Valery/Rich may well disagree and say - "No - so long as you're careful, you might as well use old-fashioned "lag-keys" to hold parent data on the way down the data tree, because that way, you never have to bother with the hashed itab."

And for me, this kind of question is intimately involved with "core SAP business development", to use the phrase that you used in your post.

Best regards

djh

[Former Member]

<b>No</b> - we have a Wiki for that.

<a href="https://wiki.sdn.sap.com/wiki/display/Community/Community+Projects">Community Projects</a>

[Former Member]

Craig -

I went to the community projects page and saw the instruction to use "ADD PAGE" to start a new project.

But I didn't see this button or link anywhere.

Can you describe where this link or button is on the community project page.

Thanks.

PS - this post is also a test of hard enters in this forum - I've tested them in the T&P forum and mentor forum, and they appear to be working.

But as you can see from my reply to Thomas Jung above, they weren't working in this forum yesterday.

djh

[Former Member]

Top right corner of the page along the line containing the "Edit", "Comments", "Info" tabs.

Or simply "Edit" the page add your entry and surround the name of the project in [and ] (in Wiki Markup mode) - save the page then you can click on the name of the project and it will automatically create the page for you.

[thomas_jung]

I guess it really depends what types of applications that you want to create. If you are mostly a UI developer than you might very well be able to stick mostly with .Net in the SAP environment.

With the advent of Enterprise Services, dedicated connectors like the .Net Connector really aren't needed any longer. Enterprise Services opens up lots of core business functionality for easy consumption in other environments - .Net not being the least of which.

But the core business logic of a SAP environment is going to remain written in ABAP and Java. You can consume services from .Net but if you are needing to alter, extend or create your own integrated business logic you are going to want to look to ABAP or Java.

There are also advantages to using one of SAP's core development technologies (Visual Composure and Web Dynpro) over .Net for SAP applications. These advantages have been discussed elsewhere - but the point is that this may limit the opportunties for .Net Developers looking for work in the SAP space if they also aren't well versed in SAP centric tools as well.

I can certainly respect a certain passion for one particular development environment. Personally although I have worked extensively in .Net, Java, and ABAP; I have a similar passion for ABAP. At the same time don't close your eyes to what other opportunites are out there. Spending time in another development environement, even if it isn't your favorite, will make you a more well rounded developer overall and increase your long term career opportunites.

[Former Member]

Thank you for that extensive reply, Thomas,

Surely I agree that you shouldn't just close with certain tools and environments, I'm certainly trying not to miss anything of potential importance.

A closer explanation would be that since some time I've been more interested in development of web-based software than traditional programs. And here .NET or exactlier ASP.NET comes very handy. If you look at modern trends with AJAX & Co. you would certainly understand my passion for this technology.

Things like http://pageflakes.com, http://netvibes.com and http://www.oazabir.com make me excited, and they are not just the pure UI. I would really be glad to contribute something like this here, but I guess this will not be apreciated by SAP.

I've tried to clarify today the situation through other sources, it looks like there is not much of that kind of work here, well... don't really know what else to say...

[Former Member]

Hi Andrey,

> Things like http://pageflakes.com,

> http://netvibes.com and http://www.oazabir.com make

> me excited, and they are not just the pure UI. I

> would really be glad to contribute something like

> this here, but I guess this will not be apreciated by

> SAP.

That's where you would be quite wrong, take for example the extensive work SAP is doing with various Scripting Languages (PHP and Ruby, Perl and Python) - most of which is being flooded into SDN. SAP is very interested in and appreciates the Web 2.0 (collaboration and sharing) space in particular the new advances in UI technologies. Many might argue that SAP is not interested or doesn't show it but that's where I would sit back and simply laugh. You have to really get a good look at the new Business Client and some of the other things going on.

Also as Thomas pointed out it's a whole new ball game when it comes to development thanks to the many services being developed and with those services you'll be able to do many a new thing. For example (watch for the blog in the next weeks) I've combined SAP and the personalized Google Homepage (just like NetVibes, etc.) without a problem. The thing to remember when dealing with services is how much you do and on what side you do it. Do you do it on the SAP side using custom ABAP to extend features or do you increase your footprint on the server/client side and grab multiple pieces of SAP and piece them together on your NetVibes module side? That of course boils down to a matter of your approach to the programming and your desire for performance and stability.

Just take a look at the Widgets here on SDN, they are really not much different than a Google Module, NetVibes module or anything else web based in theory and the possibilities are just about the same to make them happen.

[thomas_jung]

I think what you need to keep in mind is that when business <i>X</i> goes to create or extend a business application they mostly likely don't want to have to create UI technology. Companies want to spend their time and money investing in differeniating business functionality not necessarily UI. What I am talking about here is internal business process (Accounting for instance) not internet facing applciations.

This doesn't mean that businesses don't want good looking or nicely interactive UIs. It just means that they want them for free and they don't want to have to deal with the inner details of them. Nor do they necessarily want each application to interact or look differently - ie. training costs.

That said - there are opportunities to create new UI technologies and approaches in the SAP space - but those opportunities are probably more limited than your average development position at your average business.

There is creativity and challenges to be found in core business SAP development (personally I love the challenge of performance tuning a long running report. I'm the type of person that gets excited talking about shared memory object caches), but it will be of a different nature than the kind of heavy UI paradigm innovation that are in your examples.

In that space, hopefully, SAP is doing the work toward innovating so that their customers gain the benefit. Some might disagree on that point base on the current state, but even in the coffee corner I still wear the blue flag by my name. In all seriousness that is our honest goal - to have developer X (or Business Process Expert X) at Company Y to be able to create just as cool interactivity as the examples you gave - but not have to know a single bit about what AJAX or DHTML is.

Just my 2 cents worth - but that is what the coffie corner is for.

In the end, you may have fewer opportunites for the deep UI stuff in the SAP space but that doesn't mean you shouldn't go down that path. It just means that you need to be that much better to set yourself appart and go after those opportunities.

[Former Member]

I should also clarify that (I also have the Blue flag) I approach this topic from the side of a company running SAP but also with a heavy investment in a different technology area say for example company A with a massive .NET intranet deployment and a SAP Human Resources system for their 5000 employees.

Yes it would be great for them to migrate to the SAP Portal environment and take huge advantage of the HCM packages already available HOWEVER sometimes it's not practical for them to make the move or investment and in that sense a .NET developer would be in an ideal environment to take advantage of the services provided by SAP already to do the integrations, the "mashups".

So as Thomas said

> That said - there are opportunities to create new UI

> technologies and approaches in the SAP space - but

> those opportunities are probably more limited than

> your average development position at your average business.

>

So if the corporate environment is already heavy SAP (we all hope of course) then finding the spot for that .NET developer would of course be a bit harder, same for a PHP developer or what not.

I tend to disagree with Tom a bit though but not entirely. One of the things I've noticed taking place at SAP is the fact that they are approaching this from two angles one is as Tom mentioned,

> In all seriousness that is our honest goal - to have

> developer X (or Business Process Expert X) at Company

> Y to be able to create just as cool interactivity as the

> examples you gave - but not have to know a single bit

> about what AJAX or DHTML is.

Which is certainly true, just take a look at WD and VC for starters but they are also making it a lot easier for those not already into those technologies to continue doing what they are doing so if you have the knowledge use it if you'd like though we can give it to you - which I also think I need to hand it to Tom that most companies do want it and don't want the TCO to do it...

[thomas_jung]

>I tend to disagree with Tom a bit though but not entirely...

Keep in mind here that I am refering to job opportunities not product positioning. Of course SAP is working in both the approach I describe and what Craig describes.

If a company comes to me and asks me what development tools they should use I give them different advice than I have give you (this is point I wanted to clarify). I discuss where they are today and where they want to go. Some companies will go VC/Web Dynpro and some companies will go more low level. Some comapanies will do a mixture. Each will do what is the best fit for them - and that is part of the power of SAP's message to their customers.

But for this discussion I tried to put my mind in the position of someone looking for a job (first major job in the field?). Looking at what direction companies tend to choose - they seem to be more openings for business application on the use of a framework side than the low level (particularly with SAP moving really hard into the midmarket). Knowing that, it just means that it is important to find the right spot for your particular interests and skill set when going for job opportunites.

[Former Member]

I agree with most of what I read in your post Thomas, but I think the following part explain pretty well what most of people still doesn't understand about usability:

> Companies want to spend their

> time and money investing in differeniating business

> functionality not necessarily UI.

> ...

> This doesn't mean that businesses don't want good

> looking or nicely interactive UIs.

> ...

> Nor do

> they necessarily want each application to interact or

> look differently - ie. training costs.

That's sound ancient.

Design a coerent functional and reusable user interface is not fancy. People interact with software through UI, a poorly usable UI mean poorly usable software, and a poorly usable software has less value.

Business does understand that now, perfectly. Every SAP client now have experienced, in his work or leisure, different, more innovative, and more efficient UI and they do require SAP UI to conform to his average experience; and from SAP moves I can assume SAP knows that.

For instance, I recently went through a full SAP ICWC implementation and I can assure you it was painful to keep explaining to the client it have to deal with the fact the user experience and the usability of the application was not the one of the average web application they experience every day; <b>and they didn't want something nice and cute, they just wanted their IC agent to be more productive</b>.

Most of people laughed when the mouse was introduced, now most of people laugh at them.

Few companies I know are still using old cobol software with a UI 20 years old they achieve a high productivity with it, and I suggest them to stuck with it. But these are exceptions.

<b>The rule now is better usability = more productivity, and as far as I can notice business knows that.</b>

[thomas_jung]

>That's sound ancient.

I think you missed the point I was trying to make. I agree 100% that business want what you describe. What I was trying to say is that they don't want to have to build it themselves. CIOs don't want to have to hire a team of JavaScript/AJAX/"Next Big Thing" developers to write or modify their internal facing Business Applications. They doesn't mean they don't want productivity enhancements - they just want them to come from an existing framework instead of having to build a UI framework.

Companies like Google can invest in an army of AJAX developers because that is their core business. You think average Fortune 500 company wants to put a similar investment into the UI of their Accounting System? No because that isn't their core business. They want just as productive a UI as what they use on the Internet - but one that comes out of the box so they can focus the investment of their own IT Development resources on the details of their business process differeniators (core) and not UI parts and pieces (context).

[Former Member]

> I think you missed the point I was trying to make. I

> agree 100% that business want what you describe.

> What I was trying to say is that they don't want to

> have to build it themselves.

Ok, I missed it.

I agree with you 100% then, they definitely don't want to build it themself.

<b>They definitely, more and more, expect SAP to deliver it.</b>