Related
My company runs a couple of B2B apps (written in Rails) dealing with parts and inventory and we've been trying to figure out the best way to integrate with some of our bigger users. We already offer the REST-style API that comes with Rails, but that, of course requires an IT Department on their end to decide to integrate it, so we'd like to lower that barrier if possible.
From what we've found, most of them are on SAP systems. Now, pretty much all I know about SAP is it's 1) expensive, 2) huge, 3) and does everything and anything you could ever need for your gigantic business to run. Naturally, this is all a bit imposing, and the resources on the site are a cross between impenetrable buzz-word laden sales material, and impenetrable jargon laden advanced technical material with little for the new, but technically competent user to be able to sink his teeth into.
So what I'm wondering is: as a 3rd party, that's not running a SAP installation, is there a way for us to offer access to our site's data through a web service or other API? Is it just a matter of providing or implementing a certain WSDL (and what would that be)? Is this feasible for someone without in-depth experience with SAP? Or is this a complete non-starter?
I'd say it's not possible without someone who knows the SAP system. You probably won't need to hire someone with in-depth SAP knowledge, but at least for the initial implementation, you'll need both the knowledge and a working system you can develop against. Technically speaking, it's not really that hard, but considering the fact that SAP systems are designed to handle multiple organizations, countries, legal systems, localizations and several thousands of users simultaneously, things are bound to be a bit more complex than almost any other software around - and most of the time not even bloated, it's just easy to get lost in that kind of flexibility.
My recommendation would be to find a customer (or a prospective customer) who has someone in their IT department with the necessary technical and processual knowledge and who is interested in conducting a development project. This way, you'd get access to a real system (testing of course) and someone who can explain to you the basics of the system. But, as I said, be prepared for complexity.
vwegert makes some excellent points.
As to this part of your question:
So what I'm wondering is: as a 3rd
party, that's not running a SAP
installation, is there a way for us to
offer access to our site's data
through a web service or other API? Is
it just a matter of providing or
implementing a certain WSDL (and what
would that be)?
Technically it is possible to expose any of your system's services as web-services to a client's SAP system. In order to do this you do not need any prior knowledge of SAP. (SAP should be able to import a WSDL, although there may be some limitations in the earlier pre-ECC5 systems).
For example a service that provides meter reads, airport departure schedules, industry trends etc is not dependend of what is in the user's system or how they set it up. However as soon as there is a need to initiate updates to the client system's data is when you need access to more specialised SAP knowledge.
Also note that many SAP functions can also be exposed as web services, but generally you do need someone with SAP (ABAP) knowledge to do this.
The ABAP language is actually fairly simple, but there is a huge learning curve to understand the data model and the myriad of configurable options in SAP.
On the surface LabView and Microsoft Robotics Studio appear to me to have a very similar programming paradigm and environment.
Is it fair to compare these two products, or are they in different leagues?
I am hoping someone who has used both products will help compare and contrast them so that I can understand when it is appropriate to use one or the other.
Disclaimer. I have not worked with Microsoft Robotics Studio. I only looked at the fact sheet and some of the documentation. However I have a great deal of knowledge of LabVIEW. So this answer might be (and probably is) biased.
History wise LabVIEW has been around for 20 years and has the following features which MSRS doesn't have (from the first glance).
Platform independent (LV compiles on Windows, Linux, Mac and various embedded platforms), however hardware support varies
A compiler, directly into machine code
LabVIEW is a programming language not targetted at robotics but originated in Test and Measurement
Extensive DAQ and data analysis support
The VPL (MSRS) looks very clumsy compared to LabVIEW code, it looks like MS doesn't really makes the switch to visual programming (or is not allowed by patents from third parties).
Price wise, MSRS is much friendlier with a free 'hobbyist' version, while a LabVIEW base begins around $1300.
Additional MSRS does not run on the robot, it only controls the robot via the robot API (bluetooth or wired), while LabVIEW (and more specific NXT-G) run on the processer inside the robot stand-alone.
What might be important is the LabVIEW is the main software product of NI while MSRS is one of many products of MS, so support and development should have a higher priority.
Ton
I have programmed extensively with MSRDS and to a lesser extent with LabVIEW and here is my opinion. Earlier, most of our software used to developed using LabVIEW but the last few years we have been moving a major part of it to C# because it is much easier to do objected oriented programming using a language like C#. I personally feel MSRDS and in particular the Concurrency Coordination Runtime (CCR) is so underrated partly because of the not so detailed documentation. Although the MSDN forums are excellent, we are required to search through them to find out some of the things that I feel should have been part of the documentation. Another excellent source of information to refer is the book "Professional Microsoft Robotics Developer Studio" by Kyle Johns and Trevor Taylor.
Coming back to the comparison, I feel both LabVIEW and MSRDS (although I am not sure about LabVIEW Robotics) follow different programming methodologies. Although it has been targeted to Robotics, MSRDS is used to harness asynchronous behavior in any application. CCR has some excellent coordination primitives (such as Joins and Interleaves) and it makes asynchronous programming a lot easier. DSS is used to develop service oriented applications that are distributed across multiple nodes residing in the same machine or across different machines. We developed a framework for developing Laboratory Automation Systems using MSRDS. The framework is used to develop distributed component based software that is both thread-safe and responsive.
It is also worth mentioning that Task Parallel Library Data Flows in .NET 4.5 is based on the CCR concepts and also the concepts from .NET RX. I suggest you consider looking at them as well.
Thanks,
Venkat
I think Ton hit it on the nose, but there a couple key points I disagree on.
Independent of price LabView is a far superior system for automation and embedded programming. However, there is the catch that without a license LabView will break the bank a few times over. Depending on your targeted platform, you could easily spend several thousand dollars for a development environment.
Both systems do have a compiler. For a while LabView was restricted to only a few embedded environments, but with the addition of an ARM compiler there are now a huge number of supported hardware systems. LabView is compiled in real time as you program, MSDS is compiled on request (as far as I know).
LabView is absolutely targeted to robotics. NI has put forth a lot of tools for robotic applications and many of the ideas taken from automation can be dropped right into a robotics setting. As an interesting note, the FIRST Robotics Competition exclusively uses NI hardware (the cRIO) and LabView is a popular programming option.
RDS's visual programming and LabView's visual programing aren't really comparable. They don't operate by the same paradigms.
RDS does create machine code and the code can run on a robot without intervention.
If you are looking to buy a complete robotics system for development with LabView check out this page: http://www.ni.com/robotics/how_to_buy.htm
Just as a bit of background, I am a certified LabView developer and have used RDS with the lego NXT system as an instructor.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
What are SAP and ABAP? I searched and got a bunch of different acronyms that don't quite make sense.
Is SAP a database engine?
Is ABAP a programming language?
Or are they nothing of that nature?
What are they primarily used for?
I have worked with SAP since 1998. SAP is a type of software called ERP (Enterprise Resource Planning) that large companies use to manage their day to day affairs. On the macro, the software can be split into two categories: Technical and Functional
Let's go Technical first, as it answers the "What is ABAP" part of your question.
Technical
There are two technical "stacks" within the SAP software, the first is the ABAP stack which is inclusive of all the original technology that SAP was. ABAP is the proprietary coding language for SAP to develop RICEFW objects (Reports, Interfaces, Conversions, Extensions, Forms and Workflows) within the ABAP stack.
The ABAP stack is traditionally navigated via Transaction Codes (T-Codes) to take you to different screens within the SAP Environment. From a technical perspective, you will do all of your performance and tuning of the WORK PROCESSES in the SAP system here, as well as configuring all of the system RFCs, building user profiles and also doing the necessary interfacing between the OS (usually Windows or HPUX) and the Oracle Database (currently Enterprise 11g).
The JAVA stack controls the "Netweaver" aspect of SAP which encapsulates SAP's ability to be accessed via the Internet via SAP Portal and it's ability to interface with other SAP and non-SAP legacy systems via Process Integration (PI).
SAP also has extensive capabilities in the Business Intelligence Field (BI) by accessing information stored within the Business Warehouse (BW). Currently, there is a new technology called HANA 1.0 that compresses the time to run reports against these repositories.
There are two primarily technologists that run ALL of these functions, they are called SAP Basis (Netweaver) Administrators and ABAP Developers.
Functional
SAP has specific pre-populated functional packages for different business areas. For example, Exxon runs the "IS Oil & Gas" package while Bank of America runs the "Banking" package, while further still Lockheed Martin runs the "Aerospace & Defense" package. These packages were developed over time by the amalgamation of intelligent functional customizations that could be intelligently ported to the system via inclusion in dot releases.
However, there are some vanilla functional modules that almost all entities run, regardless of their specific industry:
HR: Human Resources
PM: Project Management
FI: Financial
CO: Controllers
MM: Materials Management
SD: Sales and Distribution
PP: Production Planning
and finally the biggie:
MDM: Master Data Management which encapsulates the data for customer/vendor/material etc.
SAP is a company and offers a full Enterprise Resource Planning (ERP) system, business platform, and the associated modules (financials, general ledger, &c).
ABAP is the primary programming language used to write SAP software and customizations. It would do it injustice to think of it as COBOL and SQL on steroids, but that gives you an idea. ABAP runs within the SAP system.
SAP and ABAP abstract the DB and run atop various underlying DBMSs.
SAP produces other things as well and even publicly says they dabble in Java and even produce a J2EE container, but tried-and-true SAP is ABAP through-and-through.
Attempt to provide simplified explanation:
SAP
Firstly it is a product.
Owner company, derives its name with the product name "SAP"
It is a management system (i.e. referred as ERP). Which means, this is a tool used for "managing the system" (domain specific - finance etc.).
Now, that SAP has created an environment around SAP. In order to operate in SAP environment (i.e. for customisations etc.), language-abstraction was required. Here comes ABAP.
ABAP
It is a language (high level), which is used in the SAP environment for customisations or new feature implementations.
It is high-level, because, it is known only in SAP environment.
Therefore, any customisation on the basic version of SAP given to some customer of SAP would require ABAP usage, otherwise, just delivered SAP is good enough for usage (i.e. no ABAP required).
Now is another term HANA.
HANA
This is an in-memory RDBMS.
Another tool/product by SAP, you would say, and its prime focus is to facilitate "analytics".
The way, this is designed, gives high compression (column-wise storage) and hence is majorly used for "READ" operations, which is why it is associated with "analysis".
SAP and HANA together abstracts the underlying complexity of database-access queries and UI (developed in java), together, to make the user experience good for the management system (used majorly in analytics, and so that the main focus stays in analytics). This very specific tool/product, is said as "technology", as it has an environment of its own (terminologies etc.). ABAP facilitates further development of the SAP-ERP.
The underlying development is in C, C++ (and ABAP) for SAP.
SAP SE is a German multinational that makes enterprise software. It is best known for SAP ERP and its predecessors (SAP R/2 & SAP R/3). As the name suggests, SAP ERP is an ERP system, which basically means that it supports a wide range of business processes from warehouse management and sales to HR, business intelligence, etc.
Although SAP ERP isn't the only software sold by SAP, people are typically refering to SAP ERP when they say "they're using SAP at work". It's important to note, though, that SAP is the name of the company and no software is sold or licensed as just "SAP".
ABAP is a 4GL programming language created by SAP, and commonly compared with OpenEdge ABL or COBOL. Much of SAP's software is written in ABAP. SAP provides an ABAP Workbench, which is a collection of tools that allows third party developers to develop, test and run custom ABAP programs within the SAP ERP system. The ABAP Workbench is typically used only when business logic cannot be implemented in SAP ERP by means of mere configuration.
with SAP, you might be referring to a popular business software:
http://en.wikipedia.org/wiki/SAP_AG
And according to Wikipedia, ABAP is a programming language (short for Advanced Business Application Programming) created by SAP AG.
In addition to all the regular confusion around SAP issues might also stem form the fact that SAP used to have their own DBMS ..
It used to be called Adabas (marketed originally by Nixdorf and then by Software AG) and was a quite popular DBMS for smaller SAP (the ERP solution) installations in Germany. At some point (AFAIK around 2000) SAP started to co-develop/support/take over Adabas and marketed it as SAP DB and later MaxDB under commercial and open-source licenses. There also was/is some agreement with MySQL.
But when people talk about SAP, they usually refer to the ERP solution as the other posters have noted.
SAP is just a company name and Abap or Abap/4 is a language programming. SAP company has a lot of products: ERP(material, sales, costs, financial), CRM, SRM, SCM and all of them are customizing and programmed with ABAP and Java. Basically is it.
See http://en.wikipedia.org/wiki/SAP_AG.
In short, SAP is a modular based application that sits on top of a database (as many applications do). Many people mistake SAP as being a database, but in fact it is just the application.
By 'modular based application' I mean that 'SAP Netweaver' is a bit like 'Microsoft Office' in that it is an application or set of applications that contains many components/modules. With SAP you can add modules (such as Finance, HR, Banking, Logistics, etc.) to meet your business requirements.
ABAP is a bespoke programming language that is used within SAP. SAP also now has components that are purely ABAP based, purely JAVA based or a mixture of the two. SAP can also integrate with other technologies such as .net and PHP.
SAP is really a big Company that offers incredible solutions oriented to medium-large companies.
Actually, I can say that the main IT products are: ERP, WEB, Human Resources, Integration, BI, Reports, Machine Learning, Mobile, Cloud, Robotics, and so on.
On the cloud, you can even find solutions using Cloud Foundry, NodeJS, HTML5, Java, etc.
It's really huge the solutions that offers to their customers.
I'm thinking about switching my path "slightly" by going into desktop development (VC++, MFC, C#, etc) after about 8 years within embedded telecom systems development (C, MAKE, Symbian, 100 compilers etc, etc).
My concern however is that my experience within embedded systems maybe doesn't give me much value when going into desktop development. For example that the domain specific problems and environments I've worked with for so long still doesn't give me much to negotiate salaries with since it bares little worth on the desktop.
I think this place might be good for input on this.
So, the Q:
If you disregard the obvious generic experience on programming language level, give an example of something you have learned working with embedded systems that you could reuse when working in a desktop environment.
PS:
I should note that I'm no beginner in the desktop area - since many years back all my hobby projects are focused around desktop development.
Embedded engineers in general tend to be more disciplined when it comes to validating operations and dealing with finite resources.
This can also translate into coming up with an exception handling strategy earlier on.
The quintessential example is checking the return value of malloc. I have seen very few desktop software consistently check it, but it's commonplace in embedded environments.
Discipline of having a clean, well-organized set of source-code is the key skill that translates well to the "desktop experience". -- I've noticed that the embedded projects I've written and picked up are often WAY cleaner than their desktop counterparts.
Many desktop-only developers could benefit from the experience of making a program fit in 128K of FLASH and 32K of SRAM, not to mention communicating meaningfully with a user through only an LED or two and a couple of buttons. Making that a requirement might reduce some of the endemic code bloat in the applications industry. :-)
Even if you don't switch tracks to straight application development, the embedded experience translates well to driver development, as well as to low level utilities and to long running services. All of these are also domains where the disciplines that are nearly second-nature to a successful embedded developer remain valuable.
I was a desktop developer for almost 5yrs before switching to an embedded environment.
I find working on an embedded environment more challenging as we have to deal with memory limitations, slow CPU speed, cross-compilation issues, etc.
Having learned a lot of patience, discipline and low-level intricacies, desktop development should be as easy as a walk in the park.
State machines/event driven programming on embedded systems is not that different from event driven programming on the desktop. The depth of experience you have of these coding techniques on embedded systems, especially telecoms embedded systems, should make you a great desktop programmer.
Similarly, your experience with communications protocols should transfer nicely to the desktop. Most desktop applications have some involvement with the network.
There are a couple of questions on Stackoverflow asking whether x (Ruby / Drupal) technology is 'enterprise ready'.
I would like to ask how is 'enterprise ready' defined.
Has anyone created their own checklist?
Does anyone have a benchmark that they test against?
"Enterprise Ready" for the most part means can we run it reliably and effectively within a large organisation.
There are several factors involved:
Is it reliable?
Can our current staff support it, or do we need specialists?
Can it fit in with our established security model?
Can deployments be done with our automated tools?
How easy is it to administer? Can the business users do it or do we need a specialist?
If it uses a database, is it our standard DB, or do we need to train up more specialists?
Depending on how important the system is to the business the following question might also apply:
Can it be made highly available?
Can it be load balanced?
Is it secure enough?
Open Source projects often do not pay enough attention to the difficulties of deploying and running software within a large organisation. e.g. Most OS projects default to MySql as the database, which is a good and sensible choice for most small projects, however, if your Enterprise has an ORACLE site license and a team of highly skilled ORACLE DBAs in place the MySql option looks distinctly unattractive.
To be short:
"Enterprise ready" means: If it crashes, the enterprises using it will possibly sue you.
Most of the time the "test", if it may really be called as such, is that some enterprise (=large business), has deployed a successful and stable product using it. So its more like saying its proven its worth on the battlefield, or something like that. In other words the framework has been used successfully, or not in the real world, you can't just follow some checklist and load tests and say its enterprise ready.
Like Robert Gould says in his answer, it's "Enterprise-ready" when it's been proven by some other huge project. I'd put it this way: if somebody out there has made millions of dollars with it and gotten written up by venture capitalist magazines as the year's (some year, not necessarily this one) hottest new thing, then it's Enterprise-ready. :)
Another way to look at the question is that a tech is Enterprise-ready when a non-tech boss or business owner won't worry about whether or not they've chosen a good platform to run their business on. In this sense Enterprise-ready is a measure of brand recognition rather than technological maturity.
Having built a couple "Enterprise" applications...
Enterprise outside of development means, that if it breaks, someone can fix it. I've worked with employers/contractors that stick with quite possibly the worst managing hosting providers, data vendors, or such because they will fix problems when they crop up, even if they crop up a lot it, and have someone to call when they break.
So to restate it another way, Enterprise software is Enterprisey because it has support options available. A simple example: jQuery isn't enterprisey while ExtJS is, because ExtJS has a corporate support structure to it. (Yes I know these two frameworks is like comparing a toolset to a factory manufactured home kit ).
As my day job is all about enterprise architecture, I believe that the word enterprise isn't nowadays about size nor scale but refers more to how a software product is sold.
For example, Ruby on Rails isn't enterprise because there is no vendor that will come into your shop and do Powerpoint presentations repeatedly for the developer community. Ruby on Rails doesn't have a sales executive that takes me out to the golf course or my favorite restaurant for lunch. Ruby on Rails also isn't deeply covered by industry analyst firms such as Gartner.
Ruby on Rails will never be considered "enterprise" until these things occur...
From my experience, "Enterprise ready" label is an indicator of the fear of managers to adopt an open-source technology, possibly balanced with a desire not to stay follower in that technology.
This may objectively argued with considerations such as support from a third party company or integration in existing development tools.
I suppose an application could be considered "enterprise ready" when it is stable enough that a large company would use it. It would also imply some level of support, so when it does inevitable break.
Wether or not something is "enterprise ready" is entirely subjective, and undefined, and rather "buzz word'y".. Basically, you can't have a test_isEnterpriseReady() - just make your application as reliable and efficient as it can be..