Javapocalypse in a single system
This article is focused on ABAP developers in SAP ERP systems. It contains many platform-specific points that are of little interest or even controversial for developers using other platforms.
There is such a euphemism: "historically".
So, in my main system historically it happened that:
')
And this means that without a properly configured link, Browser + Java is not easy to live.
Java is needed to work with files (upload, download). In principle, a web application should work only inside its window and it should not be allowed to access the user's file system even for a cannon shot. Files should be handled by the browser personally in a convenient way, but this is contrary to the SAP GUI approach, which wants to control everything: showing the open dialog, the title of the dialog box, the list of available file extensions, allow multiple selections, select the directory, read the directory, read the contents of the file or write . Since SAP GUI for HTML should repeat the functionality of a big brother, so they decided not to change the approach there, but to introduce an additional layer in the form of a Java applet that would perform these actions on the client side. The ABAP part with this approach remains virtually unchanged.
In addition, ZWWW works through OLE technology, without options. A web application cannot be allowed to the OLE interfaces of the client machine even within the radius of destruction of ground-to-air missiles. Consequently, we need another layer in the form of a Java applet that will proxy OLE calls and perform related manipulations.
Since the SAP GUI for HTML itself is a layer between the ABAP instance and the ITS server, this whole structure begins to resemble the game of Genga.
This game goes on all the time. Then the browsers start to disable the old Java, the Java applets lose their authority, something happens with the applet's signature verification, some black / white exclusion lists appear, then the applet suddenly begins to slow down on some version of the JRE, then it goes A new version of the office, then update ITS / ABAP, then users at the other end of the country can not set up a security policy, then suddenly it seems to someone that it is easier to set a low level of security in the browser ...
If you follow the chronology, you can see:
Soon there will be only old and not so kind IE. Even though the developer has promised to support IE11 in Windows 10, we all know ...
What happens if an accountant suddenly takes away the opportunity to upload any report to Excel? Apocalypse!
And Javapocalypse is approaching.
Consider the options.
* * *
Change browser (SAP GUI for HTML) to a full SAP GUI. Disappears for administrative reasons.
Change browser (SAP GUI for HTML) to NWBC. But NWBC is only a shell around the same IE, so this approach does not solve the underlying problems. It disappears.
* * *
Make ZWWW work on the server and dump the result to the client. Impossible.
* * *
If themountain does not go to the platform does not resemble the engine, then you can change ZWWW to another engine:
All three scenarios are laborious, but there are indications:
1. PDF is generated on the server side. The user can not correct the content. Some forms are only needed for printing (“without leaving the checkout”) and are not needed as working documents in the file form. The most simple examples are cash vouchers, cash vouchers, invoices for payment and other small forms per page.
2. Some reports are needed not only to users within the system, but also to external users, and these external users have access to the BI system. Reports do not require relevance in real time. If the report has non-trivial calculations, then you can upload the final calculations to the BI system and not force the BI system to repeat this complicated logic. Reducing the load on the ERP-system. Possible savings on the number of licenses. Work reports can remain in the system, but without uploading to beautiful Excel.
3. Any remaining can be rewritten from ZWWW to Abap2xlsx. This library allows you to generate an Excel file directly on the server. The approaches of these two libraries are radically different, it is simply impossible to replace one call with another. The speed will increase significantly, especially for complex documents. The need to support old xls formats is no longer relevant.
This is all the background, but for the sake of what I started to write something ... Suppose we rewrote the generation of the file on Abap2xlsx, but also somehow need to be thrown onto the client beautifully!
Discarding a file to a client by the browser approach can be performed using the functional method ALEWEB_DOWNLOAD. It does something, but it's not very beautiful. For example, you cannot control the file name in it, and the temporary names of random letters only like the system, and people just get sick of it. If you twist around in that area, then you can punch, finish, copy to the Z-area. Boredom!
And you can make a feint through the service and HTTP-handler. It is very interesting!
First, create a table, for example:
In this table we will add binary files that must be given to the client. The file itself is stored in the XDATA field.
HTTP handlers in the system are implemented as classes. For example, take the class CL_HTTP_EXT_PING.
Create the ZCL_WWW_FILE_DOWNLOAD class and implement the HANDLE_REQUEST method in it:
Everything is trivial:
Then we register a new service in the SICF transaction, and assign the newly created handler to it:
After this, the service will be available on the link of the form
http: // host: 8000 / sap / bc / ZFILE_DL? file_uid = 5A2D5067C04D1ED5AFB71835DF981A07
Fine! It remains the case for small: do unloading.
First, in any way we get the binary file XLSX. For example: by converting from ALV:
Then add the file to the table:
Then we kick the bootloader:
Try, draft works!
But how can the ZWWW approach apply to Abap2xlsx?
And then there is a dialogue:
On this optimistic note, I bow out. Thank you for your attention and see you soon!
There is such a euphemism: "historically".
So, in my main system historically it happened that:
- many users work through SAP GUI for HTML;
- almost all reporting is downloaded to Excel via ZWWW.
')
And this means that without a properly configured link, Browser + Java is not easy to live.
Java is needed to work with files (upload, download). In principle, a web application should work only inside its window and it should not be allowed to access the user's file system even for a cannon shot. Files should be handled by the browser personally in a convenient way, but this is contrary to the SAP GUI approach, which wants to control everything: showing the open dialog, the title of the dialog box, the list of available file extensions, allow multiple selections, select the directory, read the directory, read the contents of the file or write . Since SAP GUI for HTML should repeat the functionality of a big brother, so they decided not to change the approach there, but to introduce an additional layer in the form of a Java applet that would perform these actions on the client side. The ABAP part with this approach remains virtually unchanged.
In addition, ZWWW works through OLE technology, without options. A web application cannot be allowed to the OLE interfaces of the client machine even within the radius of destruction of ground-to-air missiles. Consequently, we need another layer in the form of a Java applet that will proxy OLE calls and perform related manipulations.
Since the SAP GUI for HTML itself is a layer between the ABAP instance and the ITS server, this whole structure begins to resemble the game of Genga.
This game goes on all the time. Then the browsers start to disable the old Java, the Java applets lose their authority, something happens with the applet's signature verification, some black / white exclusion lists appear, then the applet suddenly begins to slow down on some version of the JRE, then it goes A new version of the office, then update ITS / ABAP, then users at the other end of the country can not set up a security policy, then suddenly it seems to someone that it is easier to set a low level of security in the browser ...
If you follow the chronology, you can see:
- Firefox - will stop supporting Java applets in a year
- Chrome - even if it was once supported, it was all over
- Edge - did not support java applets, and will not support
- Oracle - refuses Java plugin support since Java 9
Soon there will be only old and not so kind IE. Even though the developer has promised to support IE11 in Windows 10, we all know ...
What happens if an accountant suddenly takes away the opportunity to upload any report to Excel? Apocalypse!
And Javapocalypse is approaching.
Consider the options.
* * *
Change browser (SAP GUI for HTML) to a full SAP GUI. Disappears for administrative reasons.
Change browser (SAP GUI for HTML) to NWBC. But NWBC is only a shell around the same IE, so this approach does not solve the underlying problems. It disappears.
* * *
Make ZWWW work on the server and dump the result to the client. Impossible.
* * *
If the
- PDF Forms
- Reports BI (BObj / BW / other)
- Alternative engine Abap2xlsx
All three scenarios are laborious, but there are indications:
1. PDF is generated on the server side. The user can not correct the content. Some forms are only needed for printing (“without leaving the checkout”) and are not needed as working documents in the file form. The most simple examples are cash vouchers, cash vouchers, invoices for payment and other small forms per page.
2. Some reports are needed not only to users within the system, but also to external users, and these external users have access to the BI system. Reports do not require relevance in real time. If the report has non-trivial calculations, then you can upload the final calculations to the BI system and not force the BI system to repeat this complicated logic. Reducing the load on the ERP-system. Possible savings on the number of licenses. Work reports can remain in the system, but without uploading to beautiful Excel.
3. Any remaining can be rewritten from ZWWW to Abap2xlsx. This library allows you to generate an Excel file directly on the server. The approaches of these two libraries are radically different, it is simply impossible to replace one call with another. The speed will increase significantly, especially for complex documents. The need to support old xls formats is no longer relevant.
This is all the background, but for the sake of what I started to write something ... Suppose we rewrote the generation of the file on Abap2xlsx, but also somehow need to be thrown onto the client beautifully!
Discarding a file to a client by the browser approach can be performed using the functional method ALEWEB_DOWNLOAD. It does something, but it's not very beautiful. For example, you cannot control the file name in it, and the temporary names of random letters only like the system, and people just get sick of it. If you twist around in that area, then you can punch, finish, copy to the Z-area. Boredom!
And you can make a feint through the service and HTTP-handler. It is very interesting!
First, create a table, for example:
In this table we will add binary files that must be given to the client. The file itself is stored in the XDATA field.
HTTP handlers in the system are implemented as classes. For example, take the class CL_HTTP_EXT_PING.
Create the ZCL_WWW_FILE_DOWNLOAD class and implement the HANDLE_REQUEST method in it:
data lt_query_string type tihttpnvp, ls_query_string type ihttpnvp. data ls_zwww_content type zwww_content. data lv_mimetype type string. data lv_filename type string. server->request->get_form_fields( changing fields = lt_query_string ). read table lt_query_string into ls_query_string with key name = 'file_uid'. ls_zwww_content-file_uid = ls_query_string-value. select single * from zwww_content into ls_zwww_content where file_uid = ls_zwww_content-file_uid. lv_mimetype = ls_zwww_content-mimetype. concatenate 'attachment; filename="' ls_zwww_content-filename '"' into lv_filename. server->response->set_header_field( name = 'Content-Type' value = lv_mimetype ). server->response->set_header_field( name = 'Content-Disposition' value = lv_filename ). server->response->set_data( ls_zwww_content-xdata ). Everything is trivial:
- Read the file_uid parameter from the HTTP request
- We get the contents of the table
- We set the HTTP response headers
- We drop the contents of the file into the body of the HTTP response
Then we register a new service in the SICF transaction, and assign the newly created handler to it:
After this, the service will be available on the link of the form
http: // host: 8000 / sap / bc / ZFILE_DL? file_uid = 5A2D5067C04D1ED5AFB71835DF981A07
Fine! It remains the case for small: do unloading.
First, in any way we get the binary file XLSX. For example: by converting from ALV:
data lo_converter type ref to zcl_excel_converter. create object lo_converter. lo_converter->convert( exporting io_alv = gr_table it_table = gt_report[] i_row_int = 2 i_column_int = 2 ).
Then add the file to the table:
data ls_zwww_content type zwww_content. clear ls_zwww_content. call function 'GUID_CREATE' importing ev_guid_32 = ls_zwww_content-file_uid. ls_zwww_content-filename = sy-repid && '.xlsx'. ls_zwww_content-mimetype = 'application/msexcel'. ls_zwww_content-uname = sy-uname. get time stamp field ls_zwww_content-timestamp. lo_converter->get_file( importing e_file = ls_zwww_content-xdata ). insert into zwww_content values ls_zwww_content. commit work and wait.
Then we kick the bootloader:
data lv_url type string. concatenate 'http://host:8000/sap/bc/ZFILE_DL?file_uid=' ls_zwww_content-file_uid '&sap-client=100&sap-language=RU' into lv_url. call function 'ITS_BROWSER_WINDOW_OPEN' exporting url = lv_url window_name = '_top' exceptions its_not_available = 1 others = 2.
Try, draft works!
But how can the ZWWW approach apply to Abap2xlsx?
And then there is a dialogue:
- And let's redo all the reports ...
- Everything?
- They are a hundred! Do we have time for this?
- There are groupings, dynamic columns and macros!
- Macros on BASIC, Karl!
Same thing but in pictures
On this optimistic note, I bow out. Thank you for your attention and see you soon!
Source: https://habr.com/ru/post/275477/
All Articles