Not directly, but via a message sent from SAP to a PLC. The point I was trying to make is that SAP has a big foothold in deep the manufacturing space and Salesforce doesn't, so you generally won't get to work on those kind of projects with salesforce.
Yeah, of course, as with any higher-level framework/system, someone has to pay for the computing required. If you go try to get a developer instance of SAP to play around with, I believe the minimum requirements was like a 4xl ec2. That's before you even start writing crappy queries :)
I think definitely Salesforce if you want to work remotely.
It's easy to get into, much smaller system in both scope and
complexity, and tons of free documentation. Get a couple of certifications, do the trailhead stuff, contact some consulting firms to tell them you're available for work and it should be easy to find work.
Getting into SAP and finding work can be challenging. They have a lot of new things from what I see but the majority of the SAP work you'll find is old non-cloud stuff that you'll basically need to have worked with at a company before to learn.
I went from SAP dev inhouse -> SAP dev consulting then jumped on the Salesforce wagon around 2011.
SAP work was enjoyable to me, partly because I was working in the manufacturing space, which I found interesting. Software-wise, it felt like I was 20 years behind everything, working on a mainframe.
Salesforce, I just immediately hated. It was just limits after limits and some crappy java-like language and html templating that took forever to deploy. It's gotten a bit better with lightning but you'll see the shit underneath pretty quickly. I also found the projects also extremely boring. Going from controlling machines and automated warehouses with SAP to projects about collecting email addresses and creating contacts felt like I made the wrong move.
tldr -- avoid getting locked into proprietary-land if you can help it
One thing I found helpful was to find a "native" transaction that does something similar to what I want then debug it. It was nice to be able to read and debug the existing "SAP" code.
Also, that was the only way I remember to find the "user exits" where you can extend an existing transactions.
I was an ABAP developer around 10 years ago, wrote a bunch of Planning & Scheduling apps/"screens" running in SAPGUI R/3 and APO for a (brand new) manufacturing plant with a new SAP implementation.
I learned ABAP in a literally one weekend and was able to make stuff really quickly. For the most part, you could just "loop at <giant_table_name>" extract what you want and show it on a screen using one of their existing ui components. There was not much UI to worry about and you know the user is getting a proper input box (for example) with a working typeahead. Honestly, I thought it was a very decent developer experience. I could focus on what I needed to do and not worry about how pretty the thing looks or if I'm querying the database optimally. I ended up writing a very complex genetic algorithm implementation to calculate optimal schedules and it was a joy.
Yes, the table names were basically in german, and abbreviated, and most things were only 8 chars long for some legacy reasons, but it really wasn't that hard to learn that VBAK was sales_orders and VBAP was sales_order_items and move on.
For the most part, the users were totally fine with SAP. It was hyper-focused for the tasks they needed. It was consistent and easily documentable. It didn't crash, it loaded super fast, it didn't eat up gigs of memory. You just load up the gui application and you don't even need a mouse once you know the shortcuts.
Having spent the last 10 years building web and mobile apps, working with salesforce and others, I miss ABAP very often.