I want to use ABAP class and it's method to send internal table to a spool.
Please help.
I don't want to use any Function Module, because it is strictly prohibited for my software.
Take a look at the class CL_RSPO_SPOOL_HANDLE. It provides an object-oriented interface to spool jobs.
(Internally, it is just a thin wrapper around different function-modules from the function-group SPOX)
Related
The ABAP documentation lists three kinds of modularization structures:
Methods. Problem: methods don't accept parameters.
Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.
Forms. Problem: are marked as "obsolete".
Is there a newer structure that replaces the obsolete FORM structure, that is:
Local to our program.
Accepts parameters.
Doesn't require ABAP Objects syntax ?
Methods. Problem: methods don't accept parameters.
I am not sure how you came to that conclusion, because methods support parameters very well. The only limitation compared to FORMs is that they don't support TABLES parameters to take a TABLE WITH HEADER LINE. But they support CHANGING parameters with internal tables, which covers any case where you don't actually need the header-line. And in the rare case that you are indeed forced to deal with a TABLE WITH HEADER LINE and the method actually needs the header-line (I pity you), you can pass the header-line as a separate parameter.
You declare a method with parameters like this:
CLASS lcl_main DEFINITION.
METHODS foo
IMPORTING iv_bar TYPE i
EXPORTING es_last_message TYPE bapiret2
CHANGING ct_all_messages TYPE bapiret2_t.
ENDCLASS.
And you call it either like that:
main->foo( IMPORTING iv_bar = 1
EXPORTING es_last_message = t_messages
CHANGING ct_all_messages = t_messages[] ).
or with the more classic syntax like that:
CALL METHOD main->foo
IMPORTING iv_bar = 1
EXPORTING es_last_message = t_messages
CHANGING ct_all_messages = t_messages[].
Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.
Yes, function modules are supposed to be global while FORM's are supposed to be local (supposed to: You can actually call a FORM in another program with PERFORM formname IN PROGRAM programname).
But classes can be local or global, depending on how you created them. A global class can be used by any program in the system. So function groups can be substituted by global classes in most cases.
The one use-case where function modules can not be substituted by methods of classes is for RFC-enabled function modules. RFC is the Remote Function Call protocol which allows external systems to execute a function module in another system via network. However, if you do need some other system to communicate with your SAP system, then you might want to consider to use webservices instead, which can be implemented with pure ABAP-OO. And they also offer much better interoperability with non-SAP systems because they don't require a proprietary protocol.
Is there a newer structure that replaces the obsolete FORM structure, that [...] Doesn't require ABAP Objects syntax ?
Here is where you got a problem. ABAP Objects syntax is the way we are supposed to program ABAP now. There is currently a pretty hard push to forget all the non-OO ways to write ABAP and fully embrace the ABAP-OO styles of writing code. With every new release, more classic syntax which can be substituted by ABAP-OO syntax gets declared obsolete.
However, so far SAP follows the philosophy of 100% backward compatibility. While they might try their best to compel people to not use certain obsolete language constructs (including adding scary-sounding warnings to the syntax check), they very rarely actually remove any language features. They hardly can, because they themselves got tons of legacy code which uses them and which would be far too expensive and risky to rewrite. The only case I can think of when they actually removed language features was when they introduced Unicode which made certain direct assignments between now incompatible types syntactically illegal.
You are having some wrong information there. Don't know what system version are you in, but this info could help you out:
Methods: They actually accept parameters (should be crazy if they wouldn't). In fact, they accept IMPORTING, EXPORTING, CHANGING and RETURNING parameters.
Forms: Indeed they are obsolete, but in my opinion there is no risk in using then, almost every standard component relies in programs made out of FORMS. FORMS are a core concept in ABAP programming. They are the "function" or "def" of many other languages. They accept USING, CHANGING and TABLES parameters.
Is it possible to use DLL injection to record the data passed in a function call and can this system be used for internal calls and external calls aswell? And how would one achieve that in rough terms?
Thanks in advance
Yes its possible. When a call is hooked, you can take the arguments and record as you like. For internal calls, you will probably need to know the VTables to hook those calls by their index in VTable.
There's a solid chance I'm misusing classes here which is why I need your help.
I've started developing with Java EE and one of the problems I am facing is I have a process which I have organised in a class, call it: "SendEmail.java".
Now let's say I have two other classes called "Thunderalert.java" and "FloodAlert.java" which will use all the methods that SendEmails.java has within it.
So I want to know the best way of using the SendEmails methods from each of the other classes.
Should I be creating an instance of SendEmails and accessing each method individually and error checking along the way (what if an exception is thrown?).. It's methods are just procedural code, so it's not really an 'object' as such
Shall I just be using the one method that runs all the other internal ones from within SendMail
Should this SendMail be redesigned as a helper class-type design?
I'm still quite new at Java EE so I'm not sure if there are any options available which I am missing
I think you should have one public method inside SendEmail class.
Btw, I would consider changing its name. I think having method send() when class is called SendEmail is not the best way (not to mention about names like call(), invoke() etc).
This is great article about this problem (The Kingdom of Nouns) in java.
What about something like: new Email(recipient, body).send()?
Or if you want to do it in a service style, I'd call it for example MailService
I am adapting RM_FM_EXCEL_TO_INTERNAL_TAB to my needs and I saw the following code:
"Get TAB-sign for separation of fields
CLASS cl_abap_char_utilities DEFINITION LOAD.
ld_separator = cl_abap_char_utilities=>horizontal_tab.
Can you confirm that there is absolutely no need to do the definition load any more, I assume this is some ancient legacy code? I never load class before using static methods or attributes and it appears to work.
As always, I'd recommend to take the official documentation as a reference:
The variants of the statements CLASS and INTERFACE with the addition LOAD are obsolete. ABAP Compiler ignores these statements.
For the case of a project requirement, I need to instantiate WsdlContractConversionContext which is not having a constructor for doing so.
Is there any work around to achieve this?
WsdlContractConversionContext is a member of the System.ServiceModel.Description namespace.
Note:
The requirement exactly is that, I am doing an implementation of IWsdlExportExtension.ExportContract and IWsdlImportExtension.ImportContract, and to unit test this implemetation I need the instance of WsdlContractConversionContext.
There are basically two ways to do that: you can either use reflection to call the non-public constructor of the class (making sure you're passing appropriate parameters to it); or you can let WCF create it for you, and use it wherever you need. The WsdlContractConversionContext is passed as one of the parameters to either IWsdlExportExtension.ExportContract or an IWsdlImportExtension.ImportContract, so you'd need to implement one of the two interfaces (exporting is usually easier, since you won't need to fiddle with WSDL-consuming tools), and force the interface to be called (you may need to hit the service metadata endpoint for that).
The post at http://blogs.msdn.com/b/carlosfigueira/archive/2011/10/06/wcf-extensibility-wsdl-export-extension.aspx has an example of an implementation of a WSDL export extension.
Update following edit in the question: many parts of WCF are notoriously hard to be unit tested. If you can't use WCF itself to create the instance, the only alternative you have is to use reflection. To create an instance of the conversion context class you need an instance of a ContractDescription (which you can create for your contract, but isn't easy), and a PortType, which is even harder. I'm afraid that unit testing your implementation of the WSDL export / import extension may not be worth the effort.