I have almost 4 months learning/working in SAP. I've done several reports and enhancements all along this time but recently I began to work in a requirement which is related to Mobile Data Entry or RF and it basically consists to add the EAN and some other data to the dynpro 2502.
I made a copy of the dynpro 2502 in program SAPLLMOB into SAPLXLRF 9502, related the user exit MWMRF502 and programmed the basic functionality of it but it is not working as I expected because this exit is very limited and it only lets me import and export a small group of data and is difficult to perform exactly as the standard.
I've been searching all over internet and a lot of people make their own implementations and other just simply change the standard. I don't know how to make my own implementation cause I don't understand all the process within and the alternative of changing the standard code would be better for performance and time spent in development but as I quoted I would have to change the standard code and that's something I would like to do only if there's no other option.
But the question is ¿Is it OK to change the standard? ¿How often is the the standard code changed in SAP implementations? ¿What would be the better alternative?
Thanks in advance.
You are asking the right sort of questions and it is good that you are not just plowing ahead without thinking about the consequences of what you are doing. Keep researching!
As far as changing the SAP standard goes, you generally do not want to copy an object to change it. For screens SAP quite often creates a user-exit with a sub-screen that can be modified by the customer. For Web-Dynpro you can use enhancement points and/or bADI's to extend the functionality.
Try to look for one of the following:
A SAP BAdI in the area that you want to change (transaction SE18),
a user-exit allowing you to change the necessary screen(s) (transaction SMOD),
explicit enhancement points within the functionality,
one of the implicit enhancement points in functionality
There are a lot of documentation on sdn.sap.com as well as within the SAP help regarding the topics above.
If none of are available, you may have no other choice but to modify (repair) the SAP standard objects. In order to be able to change the SAP standard you need to register the object(s) that you have to change on SAP OSS and get a repair key that the system needs to allow you to make changes. Always ensure that the SAP Modification Assistant is switched on when making changes, this will make your life a lot easier when you patch or upgrade your system.
If at all possible try to find an experienced ABAP programmer to help you with this.
Also see this question regarding changing SAP standard code:
Edit: Thomas Weiss on SDN has a helpful blog series on the enhancement and switch framework.
Always make sure that there's absolutely no other way to implement the functionality you need. If you're sure about that, then either write your own implementation from scratch, or simply change SAP's code. Just don't copy SAP's programs to the customer namespace, because I can guarantee you that that'll turn into a maintenance nightmare. You'll have to decide yourself whether the size of the change is worth the time building your own implementation, or changing SAP's.
If you decide to change SAP's code, keep in mind that all changes will pop up for review when the system is upgraded, which will take time to evaluate and adjust to the new SAP code.
Your options are, from most to least desirable:
Check the documentation of the application on help.sap.com for possible extensibility scenarios. There are many ways how SAP intends for you to customize their applications through various kinds of event architectures. Unfortunately any attempts by the various departments at SAP to agree on one event architecture and then stick to it failed. So you have user exits, BTEs, FQEVENTS, BAdIs, explicit enhancement spots and many more. If you want to know what's used by the application you need to change, RTM.
Use an implicit enhancement spot. Enhancements are a great way to modify standard software in ways SAP did not anticipate, because they are easy to disable and usually pretty stable during upgrades (use the transaction SPAU_ENH after an upgrade to confirm that your enhancements still make sense in the new version of the program). You will find implicit enhancement spots at the beginning and end of every include and every kind of subroutine, which allows you to inject arbitrary ABAP code in these locations.
But sometimes there just is no implicit enhancement spot where you need it to be. In that case you can copy the whole program into the customer-namespace and modify it. This gives you the freedom to do whatever you want with the program while still retaining the original program as a possible fall-back. It is usually a good idea to use as many components from the original program as possible, by including its includes or calling FORMs from the original program via PERFORM formname IN PROGRAM originalprogram. The main problem with this method is that after a new release, your program might no longer behave as expected. You will have to look at the new version of the program and see if there are any changes you need to port to your version. And there is nothing in the SAP standard that assists you with this maintenance task. So you are responsible to keep a list of all your copies of standard programs.
Just modify the program directly. But this is really a last-resort option for programs that are too complex to copy into the customer-namespace. The problem with this is that it means SAP will no longer offer you support for that program. If you post a ticket about that program on launchpad.support.sap.com, and they find out you modified the program, they will assume it's your own fault and close the ticket. But fortunately, when you upgrade your system, you have the transaction SPAU that will help you to merge your changes with the new versions of the modified SAP programs.
Related
I often share ABAP code via forums, github and so on, which is often intended to work on any ABAP-based system. Unfortunately, it often happens that some of the objects I use (database tables, types and so on) only exist in the solution I am working with (for instance C/4HANA which works on an ABAP system).
It's important to understand that there are several solutions developed by SAP, which are independent from other solutions, but are to be installed on an ABAP system, which includes the ABAP language itself and closely-linked external objects like those in the ABAP dictionary. Such SAP solutions are SAP R/3, SAP CRM, SAP SRM, SAP SCM, SAP BW, S/4HANA, C/4HANA, BW/4HANA, SAP Solution Manager, etc.
For instance, let's say I want to ask a question about the join in ABAP and I provide the following example (that I developed on a C/4HANA system, but the question doesn't concern C/4HANA):
REPORT.
DATA gt_partner TYPE TABLE OF crmd_order_index-partner_no.
SELECT DISTINCT a~partner_no
INTO TABLE gt_partner
FROM crmd_order_index AS a INNER JOIN crm_jest AS b
ON a~header = b~objnr
UP TO 10 ROWS.
cl_demo_output=>write( crmd_order_index ).
Many people have S/4HANA, not C/4HANA, so the code won't compile on their system because the database table crmd_order_index exists only in C/4HANA. Probably those people won't answer or they won't be able to verify their answer, so I think I could make an effort to improve the example and make it work on any ABAP system. This is of course a very simple example, but imagine that you have tens or hundreds of lines.
I know that one solution is to install an ABAP Developer Edition on our own laptop, because it contains the minimal ABAP configuration, and test the ABAP code on it. But it's relatively complex and long to install, occupies a lot of disk space, just to check a "simple thing".
Is there another way to check easily and quickly whether the ABAP code compiles in any ABAP-based system? Or any other idea?
I would also like that this solution applies to code as big as abapGit for instance.
For information:
One well-known ABAP tool which works in any ABAP-based system is abapGit.
The question is not about the versions (for instance for checking that ABAP code made on an ABAP 7.52 system compiles on ABAP 7.0 systems) because I think it's a much more complex problem.
In StackOverflow, an ABAP question whose code doesn't work on any ABAP system weakens the principle of Minimal, Reproducible Examples.
The cleanest way to share a piece of ABAP sample code seems to be this:
create a local package such as $MY_SAMPLE,
copy all sample code and dependencies in,
push it to a new, clean https://www.github.com repository with abapGit, and
add a README that provides the ABAP version the code was written for.
With these best practices:
Reduce the code and dependencies to the minimum required to make the sample work. Remove calls to other development objects not directly related to the problem. Restrict yourself as much as possible to the functions and APIs available from the ABAP platform.
If there are dependencies that form part of the problem, for example in "How do I use the CRM function module XYZ?", or that cannot be copied for size or copyright(!) reasons, identify the SAP software component they are a part of, and list it as dependency in the README.
Verify that the example compiles and works by executing it. This is not reliable, as it may accidentally still access un-copied dependencies you forgot to copy, but it will at least give you an idea.
ABAP is not really special here. Providing minimal working examples is always an effort, in any development language. It requires disentangling the affected code from unnecessary dependencies, and replacing the required ones with minimal working stubs. This is part of why asking good questions is hard work, and why StackOverflow appreciates good questions with reputation.
Sandra I dont think there is a good nor easy answer to this problem. We have been suffering for years with this problem. I got burnt so often with ABAP language across releases. Especially SQL and ABAP unit Tests. Even good old char02 burnt us last week. Yeah Char02 is an industry specific data element no longer supported in s/4 Hana. You need to have every possible release of sap abap be sure all is ok. There is a remote syntax check option, which sounded good at first. However it starts with 7.02 SP14 . So its no good for 7.0 And you need access to these releases in the first place. Who can afford that? Why cant 1 ABAP system be able to do downward compatible checks. :( No Big surprise to me ABAPGit has settled on a recent but not latest abap version as "current version". We have to support code for 7.0 to 7.5+ since we have customers from S/4 hana to 7.0 with 1 code base. We also have a common code base with a SolMan/ CRM and SAP gateway and ECC Business suite. Keeping that code base clean for all environments is easier said than done.
As far as examples go Sticking to strictly ABAP NW examples sounds easy, but unless you limit yourself SFLIGHT or tables like T002 / T006 it is harder than people realize.
A basic but not perfect solution is to check the development class of all objects in a transport before release. We have been doing that for some time. tracking what is a valid Basis object for what purpose is HARD. I have used basis objects that dont exist on 7.2 systems and Failed on import. You can then add a TADIR date to your checks.
At the end of the day I just import into the oldest (7.0) system as a smoke test.
Ill be watching to see if someone has a magic bullet solution :)
Good luck
Since the releases are downwards compatible you can set up a system with a very low release and develop your code on this.
ABAP OO was introduced with release 4.6C
Usually when I'm writing an example, for posting in my blog or somewhere online, I use the travel objects, tables like: sflight, spfli, scarr, etc, which usually are present in most systems, I don't know if they are present in C/4, solution manager or some other solutions, but I think that's probably the best objects to use.
Also another thing that's probably a good idea is to use classic ABAP, and by classic ABAP I mean not using sentences that are only compatible with ABAP >7.40, because in my experience there are still systems on SAP BASIS 7.31.
It's also probably a good idea to use classics reports, unless you are obviously writing about OOPs or the new ABAP 7.40 like sentences.
Your question in not simple as that seems. As you see, the abap code depends on customer repository so you need to have a knowledge of every system to get your code simple and fast.
For the select, you have to know all type of abap possible select.
Best ways is to declare your Types wich contains all of your table so you can select in database without a select distinct. If you have to use a Function or, a class or any kind of object that does not exist on that system, you can create it. Sometimes create is not a best way, so you can search and memorize the oldest functions/calss/object. For example, the function conv_exit_alpha_input you can use now a simple row wich do the same.
So if you want to implement an example abap code, you have to respect the KISS rule and declare as much as you can like readme or creating view or table ect.
We have an S/390 mainframe at my new job that’s been running COBOL applications since the late 90’s. The mainframe is getting old enough that we need to migrate to a newer system. We’re a small enough business that we can’t warrant spending the money to upgrade to new mainframe hardware and the program logic has been a constant work in progress for 30+ years, so it has a lot of functional value. I’ve been considering moving the functionality to a Linux machine and using something like OpenCOBOL to recompile as an executable binary instead of trying to rewrite it in a newer language. I haven’t messed with a mainframe enough to have any clue how or where to access this information and the gentleman that wrote all of the programs is unfortunately no longer with us. I’ve read that SSH is an option, but I’m not even sure how to get the ball rolling on that with a mainframe. I use Linux on a fairly regular basis, so I’m familiar with SSH, but from my understanding those mainframes aren’t a simple OS that you can merely connect to and navigate the file system to retrieve data like we can in modern operating systems. Can anyone give me some pointers to get a sense of direction for accessing the source code for the COBOL programs? Are there default locations that they are stored, etc.? They’re somewhat simple programs that don’t use any DB2 functionality and will hopefully compile on a different system with relatively minimal debugging and fixes. I’m certain that I’ve left out necessary information that would help getting an answer to this question, and I can provide any additional information that is needed to help you all help me. I suspect that SSH isn’t enabled by default, but maybe I’m wrong there too. Any assistance is greatly appreciated. Thanks everyone!
Although not a programming question I'll provide some guidance I think might help you.
First, this is a business decision about where to invest.
Do we upgrade the system to a newer model and upgrade some software and acquire the skills to keep the system running? (System Programming, OS upgrade and cost of migration, newer platform (used z13 could be an economical option, storage systems to support the mainframe)
Migration of existing workloads to other platforms. (Cost to migrate code, sizing of performance needs, new technologies to replace existing access methods like VSAM or dare I say ISAM if the applications are old enough)
Status Quo ... leave things where they are and keep the lights on
In evaluating any option you have to assess the risk to the business and what would a disruption cost? IMHO, its less about a technology like SSH or COBOL on Linux but requires some serious assessment of the current state, the acceptable to be scenarios and the cost of pursuing one of those options.
My comments are not intended to instill fear but provide a framework of how do I approach analyzing a challenge of this magnitude.
There is no default location where source code is stored on z/OS (it is z/OS you're talking about, right?). Source code is usually stored in PDS data sets. The naming of those depends on the installation, i.e. the company, and whether or not any software like Endevor, ChangeMan, etc. is being used to maintain the sources.
Since this is old z/OS (OS/390) COBOL code, chances are the code is making use of OS specifics such as record level I/O, VSAM data sets, etc. These are the parts that will not work on a non-z/OS platform without major rewrite. So, you will need to look into the sources.
SSH is available on z/OS, but it needs to be configured and enabled. You need to check with your z/OS sysprog. FTP, and NFS are other options, but again, they need to be configured and enabled.
Transfering the sources is the least of your problems, I'd say.
I have to agree with the prior two answers, but have some additional suggestions. This is a business decision what to do on the system.
Finding the program to understand what it does is the first requirement. Since you know what program is running that may be the name of the source file. That you will need to find. The source file probably will be in some library manager, the first place to look is in the ISPF menu system. There will be an option for the library manager you are using if you are using one. Based on your description you may be using something called SCLM which would should up, or you might see Librarian or Panvalet. You will need to get into ISPF by connecting using a 3270 connection emulator. Once you find the file, using FTP or SFTP may be the best, or your emulator may just provide a transfer mechanism. You will need to find the related files as well, which should also be defined in the library manager.
Once you have the file, you will need to figure out what it uses as mentioned above, it will be working with some kind of data file, and that will be the biggest part to deal with.
If it is a batch program it is probably part of a schedule, and there are other programs also running that you will need to find and figure out how they fit together.
Once you have an understanding of all the parts then you can work to make the right business decision as to how this should be run. You may want to upgrade, you may want to look to getting z/OS as a cloud service if you don't want to upgrade but you want the function. Or it may be a simple program you could move. That will be much easier to figure out once you have the details.
You say the program logic has changing for 30+ years. Was it only one person making all the changes ? Would anyone on the team have some idea about the PDS's that the user had access to ? That might be one of the places to look for. As the previous answers suggested , most shops would have store the source code in some kind of config mgmt tool like SCLM or panvelet. If you have access to the load code, there are utilities that can be used to inspect the load member to get a CSECT listing which would have the names of the obj members that make up that load.You can check with your mainframe admins. That can get you the source code file names. We use SSH from USS in our shop to move code from a HFS folder to gitlab. I have also used plain FTP to just transfer source code files to my workstation . But yes, first you have to find where it is stored.
We are interested in using Odoo but we would need to modify it slightly for our use case, for instance modifying partner by adding fields, and integrating with an external system.
Is it best to fork it or to make a module with the changes in? The changes would be quite specific to our use case and existing system so it's unlikely it would be useful to anyone else as a module/app.
My thinking is that by forking it would be easier to stay up to date with Odoo - we just have to pull in changes from upstream occasionally. It seems like with a module you would end up with lots of stale code that's difficult to update because you've moved it outside the source tree.
It also seems like it would be easier to deploy because you have all the code in one place rather than two.
As from my POV and according to many years of ERP - experience, it is the best advice to implement those kind of changes always in an own module (inheriting all the required standard components) and leave the standard untouched. This applies also for very specific customizations as well as for general improvements.
This procedure provides you with the best flexibility in installing, updating, distributing and maintaining your code while not being touched when updates to the standard modules are carried out on the target systems.
You will also be able to share and move your code between dev/test/prod systems and applying a version control on it.
Please always make sure to be in line with valid license obligations applying to your code (especially when inheriting standard modules).
Hope this helps ;-)
What do you prefer (from your developer's point of view) when it comes to implement a business process?
A Business Process Management System (BPMS) or just your favorite IDE with the needed tools and frameworks (a reporting tool for example)?
What is from your point of view the greatest Benefit of a BPMS compared to an IDE with your personal tools and frameworks?
OK. Maybe I should be more specific... I got to know one specific BPMS which should make it easy to implement a business process by configuring rules. But for me as a developer it is hard to work with the system. I would like to work with text files which I can refactor and I would like to be able to choose the right technology or framework for the job I have to do. Instead the system forces me to configure.
There are rules where I can use java, but even then I have to stick to the systems editor without intellisense etc.
So this leads me to the answer of my own question - I would like to use the tools I am used to instead of having to learn how to work with a BPMS (at least the one I know) because it limits me more than it helps. The BPMS I know is a framework from which it is hard to escape! At this time, I would prefer a framework like Grail over any BPMS I know.
So maybe the more specific question is: do you feel the same or are there BPMSes which support you in beeing a developer and think like a developer or do most of them force you to do your job a different way?
In my experience the development environments provided by BPMS systems are third rate, unproductive, and practically force you to write hard to maintain, poorly designed code (due to their limitations). Almost all the "features" (UI, integrations, etc) provided by the BPMS system I'm familiar with (the one sold by that company named for its database) were not worth the money we paid.
If you're forced to use BPMS, as a developer, my advice would be to build as much of your application in a conventional development environment, such as Java or .Net, build as little as possible in the BPMS environment itself, and integrate the two. The only things that should go in the BPMS is the minimum to make the business process work.
Not sure what exactly you ask, but the choice BPM vs. plain programming will depend on the requirements. A "business process" is a relatively vague term in software engineering.
Here are a few criterion to evaluate your needs:
complexity of the rules - Are the decisions/rules embodied in your process simple, complicated, configurable, hard-coded?
volatility of the process - How frequently does your process change? Who should be able to make the change?
integration need - Is your process realized using multiple heterogenous services, or is all implemented in the same language?
synchronous/asynchrounous - Is your process "long-running" with the need to handle asynchronous actions?
human tasks - Does your process involves human interaction, with task being assigned/routed to people according to their roles/responsibilities?
monitoring of the process - What is the level of control you want on the existing process instances being executed? Do you need to audit the actions, etc. ?
error handling - Depending on the previous points, how do you plan to deal with errors, or retry of faulty process execution?
Depending on the answer to these questions, you may realize that your process is closer to a simple state chart with a few actions and decisions that can be executed in a sequence, or you may realize that you need something more elaborated, and that you don't want to re-implement all that yourself.
Between plain programming and a full-fledge BPM solution (e.g. Oracle BPM suite which contains BPEL, rule engine, etc.), there are intermediate solutions such as jBPM or Windows Workflow Foundation and probably a lot of others. These intermediate solution are frequently good trade-off.
I have worked with Biztalk in the past and more recently with JBPM. My opinion is biased against BPMs for the following reasons:
Steep learning curve : To make a process work, I have to understand how the system and the editor works. It is hard enough for a developer to understand the system, let alone a business user. The drag and drop and visual representation is a great demo tool. It certainly impresses managers (who ultimately pay for it), but a developer's productivity just drops.
Non developers changing the workflow : I haven't seen one BPM solution do it flawlessly. Though it doesn't look like code, right click on the box and you do have to put some code, otherwise it is not going to work. So you definitely need a developer to do it. The best part is that it is neither developer friendly nor business user friendly, just demo user friendly.
Testablity and refactoring : It is virtually impossible to test drive a BPMS. You do have 'unit test frameworks' advertised, but most of them are hacks and hard to use. Recently I tried the JBPM one; I ended up writing a lot of glue code and fake workflow handlers to make it work. The deal breaker for me though is refactoring. If the business radically changes it's mind about how a business process should look, then good luck re-arranging the boxes, because just re-arranging them won't work, all the variables bound to the boxes also need to be re-arranged. I would prefer the power of the IDE and tests to refactor my business process.
If your application has workflow, then you could try a workflow library (with or without persistent state). It will still manage your workflows without all the bloat that comes with a BPM. If a business user needs to understand the code, then let the business prepare good process flowcharts and translate them into good domain driven code. Use cucumber style acceptance tests to make bring the developers and business together. A BPM is just something that tries to do too many things and ends up doing all those things badly.
BPMS-- a lot of common business case, use case are already implemented. So you just have to know how to use it. For common workflow, you don't even need to write a single line of code, though mostly you would have to write some scripts to cover things that are not yet implemented.
Plain programming-- just use the IDE to hack out the code. The positive side: more control. The negative? A lot of times are spent on rewriting boilerplate code. And you have to maintain them.
So in a nutshell, I would prefer a Business Process Management System. One that I would recommend is ProcessMaker. It features an intuitive process designer that allows you to design workflow with drag and drop. And you can always write trigger to extend the process functionalities. It's open source as well.
Wizards can kick-start features. They can also obfuscate your code, and are anti-YAGNI.
On balance, do you think Wizards are more useful or more harmful?
They are more useful than harmful if and only if you understand the code they generate.
Only after you mastered the problem the wizard is trying to solve they are really useful.
Otherwise you'll hit walls later in the project, because the generated code will need modifications at some point.
"The Law of Leaky Abstractions" really nails it on the head.
They're there for a reason - to try and make your life easier.
They can be useful and save you 5 or 10 minutes of typing. Of course it's best to read and make sure you understand what they've written for you.
If you use them without understanding, then they could be considered harmful in the fact that they're letting you get away with not learning something you should probably know, but on balance I think they're a good thing.
Wizards are good if and only if you can get away with never editing the code that they generate. In that situation, they are in essence a very high level programming language. When you change your mind about something that was generated by the wizard, you can run the wizard again.
Wizards are most horribly evil if you must ever edit the code that they generate. If you do this, and later change your mind about one of the choices that you made in the wizard, then you are forced to choose between two very bad options. You can rerun the wizard, and reapply the manual edits, or you can try to edit the multiple copies of the boilerplate code that the wizard created the first time around. In the former case, you are likely to forget at least one of your edits, and in the latter case, you are likely to miss at least one of the places in the code that was affected by your choice at wizard running time.
Wizards are "mostly harmless" when they generate an encapsulated entity - a function, a class or a set of classes - which you don't need to modify and which you interact with through a well-defined, well-designed interface.
On the other end of the spectrum is a wizard that that generates skeleton code that needs to be extended and modified. This is especially troublesome if you can't change some of the wizard option later without losing your edits.
These are still "ok" for the pro who could write the same code by himself and uses the wizard to save time. However, when they are used to make something complicated look easy for beginners, they are a paint job over a rusty car: they help selling something that you otherwise wouldn't buy.
In practice, they may still be useful to ease adoption of a platform. But that's a business aspect, and whether business aspects may justify code blunders is a question of the development environment.