Introduction
Fast RFC serialization speeds up RFC-communication by factors and is easier to manage than other RFC serializations. It is required for all scenarios with t/q/bgRFC in the cloud and brings great advantages for all RFC communication with S/4HANA releases. Therefore, you should use fast serialization for all new RFC scenarios. Due to its optional compatibility with classic serialization and basXML, it’s also easy to use fast serialization for existing RFC-scenarios – based on classic serialization or basXML – , if you want to speed up data transmission or profit from fast serialization’s other advantages.
Fast serialization is delivered with ABAP Server 7.51 and available with NW RFC SDK 7.50 and Java Connector for SAP Cloud Platform. Its delivery with SAP Java Connector oP and SAP .NET Connector is planned. It is also available down to ABAP 7.00 via Innovation Kernel 7.22 and some minor ABAP-correction instructions (needed for client-side-use of this feature) that you can get via the respective support package or specific corrections in case you do not want to install the respective support package (you find more details on this below.)
And what’s best: Using fast serialization does not require any code changes in the application code. Just select and configure fast serialization for the respective destination in transaction SM59. That’s all it takes to profit from fast serialization’s many advantages:
⚫ It is faster by factors than the other RFC serializations by using different highly efficient compression algorithms for LAN and WAN respectively.
⚫ Its high WAN compression can reduce your network bandwidth costs.
⚫ Fast serialization has a uniformly high performance for all parameter and data types
⚫ Therefore, developing, and configuring high-performance RFC scenarios does no longer require complex expert knowledge.
⚫ As another consequence of this uniformly high performance, there is no longer the risk of slowing down the RFC by permitted parameter extensions.
⚫ Fast serialization offers a dedicated feature – fast serialization’s S/4HANA mode – that address problems which might arise in RFC scenarios with and between S/4 HANA systems due to incompatibly changed DDIC data types in every S/4 HANA release – this is why fast serialization is recommended for all RFC communication with and between S/4HANA releases, because
⚫ Fast serialization enables the Application Interface Framework to monitor and adapt the payload of t/q/bgRFC, which is essential for efficiently managing queued RFCs in a cloud environment. For this reason, usage of fast serialization is required for queued RFC communication (t/q/bgRFC) with S/4HANA cloud.
⚫ Using fast serialization for existing RFC scenarios requires no code changes, because it offers compatibility modes that emulate the respective interface contract of classic serialization and basXML.The emulation mode as well as the S/4HANA mode are configured in the RFC destination in transaction SM59 – and not in the code of an application that uses RFC communication.
Availability of Fast Serialization on the ABAP Server and RFC-Based Connectors
This is feature is generally available as of ABAP release 7.51 and has been downported down to ABAP server 7.00. The server side of fast serialization for releases <740 is available via innovation kernel 7.22 (for the required kernel patch level cf. SAP note 2418683).
Fast serialization is also available as of NW RFC SDK 7.50 and Java Connector for SAP Cloud Platform. Its Implementation in Java Connector and .Net Connector oP is planned.
Note: As any other connectivity feature, fast serialization can only be used, if both sides of an RFC scenario support this feature.
Improvements and Advantages of Fast Serialization in More Detail
Higher Performance
RFC already has a higher performance than other communication technologies of the ABAP server, which is why RFC is the ABAP server’s technology for heavy-load-scenarios – such as, for example, a single transfer of a huge data load with a huge internal table or transmitting small amounts of data many times.
Fast serialization is faster than classic RFC/XRFC serialization and basXML by large factors and increases RFC’s lead in performance even more: Extensive performance measurements (when transmitting 500 – 50.000 lines of the 231 columns (2 – 200 MB) of SFIN’s ACDOCA table filled with test data in WAN and LAN scenarios) have shown strong performance improvement factors:
Compared to classic RFC fast serialization is:
⚫ 5 to 12 times faster in LAN and 15 to 1829 times faster in WAN.
Compared to basXML fast serialization is:
⚫ 7 to 16 times faster in LAN 3 to 6 times faster in WAN.
(As for the WAN results, the factors reflect the relation of the respective data sizes, because measurements with a WAN simulator have shown that for latencies higher than 100 ms the time needed for the data-transmission is proportional to the data-size that is transmitted.)
An important reason for these strong performance improvements lies in the fact that fast serialization uses different compression algorithms for LAN and WAN scenarios:
⚫ In WAN, a high compression rate is the primary goal both to reach a high performance and to minimize network bandwidth costs. This is why, in WAN scenarios, fast serialization uses a highly efficient compression algorithm with a high compression rate and, to some degree, ignores the time needed for the data compression.
⚫ In LAN, however, fast serialization uses a compression that has a good balance between payload reduction and the time needed to process the compression algorithm – because in LAN compression speed and compression rate are equally important.
Uniform Behavior
⚫ In any given scenario, fast serialization uses the same strong compression for all parameter types (tables, exporting, importing, and changing parameters) as well as for all data types, whether they are flat or deep (a data type such as an internal table, a string or an Xstring is deep, because its size is not known at design time). In contrast, classic RFC serialization cannot at all transfer a structure or table containing deep data types, but sends them via XRFC, which, in turn, cannot compress any datab. This explains why classic serialization’s performance in WAN is particularly low in situations, when deep data are involved in a transmission, while fast RFC compresses all data in all parameter types -whether they are flat or deep – with the same algorithm.
⚫ While basXML throws an error in case of illegal data in RFC parameters such as, for example, characters in NUMC or illegal entries in date and time fields – which are sometimes used by developers to signify a particular condition -, fast serialization’s behavior is consistent with the rules of ABAP compiler and can transmit this illegal data, unless they cannot be correctly interpreted on the receiver side.
No Expert Knowledge Needed for High Performing Data Transmission via RFC
Since fast serialization offers the same high performance for all data and parameter types, you no longer need expert knowledge to design high performing RFC scenarios or to avoid unknowingly slowing down the data transmission by some inappropriate parameter extension. When using fast serialization, it is not possible to deteriorate the compression rate by adding an unsuitable extension to a table or structure in a parameter: For example, adding a short string (deep data type) to a structure that contains only flat data types has no influence on fast serialization’s performance. As already mentioned, fast serialization can also transfer invalid data such as “88888888” in a time field – provided the data can be correctly interpreted on the receiving side (while basXML always throws an error when parsing illegal data) and you can also transmit constant values (not possible with classic serialization and basXML), which also makes RFC behavior more uniform.
Compatibility Modes for Using Fast Serialization in Existing Scenarios
Fast serialization offers dedicated compatibility modes that emulate basXML’s and classic serialization’s interface contract respectively. You should use these compatibility modes when using fast serialization in scenarios, in which another serialization has been used before, because they emulate even special features of basXML’s and classic serialization’s interface contract and make fast serialization behave exactly as the serialization it emulates – with the exception of some minor, outright errors in the behavior of both serializations that are corrected in fast serialization emulation modes (for further details, cf. below in the section on how to configure fast serialization).
These emulation modes are needed for compatibility reasons, because both classic serialization and basXML are extremely tolerant in situations, in which the technical properties of RFC parameters differ between client- and server side. This tolerance is required, because often in scenarios that connect different releases the parameter properties, in particular of tables and structures, differ between client and server side. RFC is expected to transmit parameters despite differences in their technical properties between client and server side – some older applications may even rely on this tolerance of RFC – , and therefore classic serialization and basXML can handle even extreme differences in parameters between client and server side without stopping the transmission: For example, classic RFC can come to terms with a character field of length 12 being mapped to two fields of length 6 on the receiving side or a field having different names on client and server side, while basXML simply truncates the data content without throwing an error, if a character field in an RFC parameter is too long for the respective data field on the receiver side.
Still, in general, the other two serializations do not tolerate the same deviations: Often, classic serialization tolerates technical differences in parameters that lead to an error in basXML, and vice versa. For this reason, fast serialization cannot offer one emulation mode for both serializations, but needs a dedicated compatibility mode for basXML and another one for classic serialization.
Using Fast Serialization Does Not Require Any Code Changes
Not only can you expect fast serialization to behave like the serialization used before in existing scenarios – provided you choose the right emulation mode -, but you achieve this compatibility without any code changes in the “CALL FUNCTION”-statement: There is no need to adapt any program code when activating fast serialization for an existing RFC scenario. Just select the suitable interface contract (for classic serialization or with basXML respectively), when you configure fast serialization in transaction SM59.
Fast Serialization’s S/4HANA Mode Is Recommended for All External Communication With and Between S/4HANA Releases
Fast serialization’s S/4HANA mode avoids unnoticed data loss that otherwise might happen in the RFC communication with and between S/4 HANA releases due to data truncation. This mode prevents data loss due to truncation going unnoticed, because – unlike classic serialization and basXML – fast serialization throws an error, when data truncation leads to content loss during an RFC transmission.
Incompatible changes of DDIC data types – most times increased field length – with every S/4 release and these DDIC types being widely used in the parameters of RFMs generate the risk of data loss in RFC communication with and between S/4 releases and, what is even worse, the risk of losing this data in the RFC transmission without RFC users even getting informed about lost data: If data is too long for the respective field on the receiver side, basXML and classic serialization silently truncate this data without throwing an error.
Suppose you have a character field with an increased field length of 8 on the sender side, but with the original field length of 4 on the receiving side. Obviously, a character sequence of length 8 cannot be moved into a character field of length 4 without truncation, which means that part of the data is irrecoverably lost. In this case, it is important that there is no silent truncation as with classic serialization and basXML, but that you get informed about this data loss – and this is what fast serialization’s S/4HANA mode always does in situations like this.
In order to avoid this possible data loss due to incompatible changes of DDIC types, SAP has blacklisted a large number of RFMs that are affected by this risk and has forbidden any external access to these RFMs in the relevant S/4 releases – if SAP so far has not adapted the interface of the respective RFMs in a suitable way such as to preclude possible data loss in communication over RFC.
Fast serialization’s S/4HANA mode mitigates the possible impact caused by incompatibly changed DDIC types on your RFC scenarios in two ways:
1. Fast Serialization prevents any data loss caused by truncation from going unnoticed: In sharp contrast to classic serialization and basXML, fast serialization always informs you about any data loss due to truncation during RFC transmission by throwing an error message that contains information about the data field and even the exact row and column – in case of a table – that is affected.
2. Quite a number of RFMs that are blacklisted due to DDIC changes are still externally accessible, if fast serialization is used: Several RFMs blocked for external access in S/4 releases are exempted from this blacklist and can be called externally, but only if these RFMs are called via fast serialization.
Note: To some degree, fast serialization’s S/4HANA mode intentionally neutralizes fast serialization’s emulation of classic serialization or basXML: When you select S/4HANA mode and fast serialization’s compatibility mode for classic serialization or basXML, in principle, you get an interface contract that is compatible with the chosen serialization, but with the exception that – unlike classic serialization or basXML – fast serialization will always throw an error, if content gets lost due to truncation.
⚫ In general, fast serialization’s S/4 mode is recommended for old and new RFC scenarios, for the reasons described above (cf. items 1 and 2), if at least one partner in an RFC scenario is on an S/4 release.
⚫ If you use fast serialization for an existing RFC scenario that connects two older (<750) releases, it is up to you
- whether you want to prevent any data loss from going unnoticed and therefore select the respective emulation mode plus S/4HANA mode or
- whether you prefer exactly the same behavior as before by selecting the respective emulation mode and deselecting S/4HANA mode – because, for example, in your scenario a transmitted character-field is split into two fields on the receiving side, which results in an error, when the S/4HANA mode is active.
Note: For obvious reasons, S/4HANA mode does not interfere with or indicate the complete omission of structure components or table columns used in RFC parameters, if these components or columns exist only on the sender, but not on the receiver side. As a consequence, in these cases no error is thrown:
On higher releases, new components/columns are often added to structures and tables used in RFC parameters according to the rules of the respective RFC serialization. The silent omission of these components or columns that only exist on the release of the RFC sender, but not on the release of the receiver-side is intended and a compatibility feature that enables smooth RFC communication between systems on different releases.
It makes good sense
⚫ That fast serialization’s S/4HANA mode does not signal an error, if complete structure components or table columns are sometimes omitted in inter-release RFC communication, because this omission is no error, but intended and useful.
⚫ That an error is thrown by the S/4HANA mode, if the content of data fields gets truncated in an RFC transmission – because unintended loss of data due to truncation is an error and the customer should get informed about this.
Monitoring and Adapting the Payload Of Queued RCF Calls With Application Interface Framework Requires Fast RFC Serialization
Fast serialization is required for RFC communication with S/4HANA cloud, because only fast serialization enables you to monitor queued RFCs (bg/t/qRFC) with Application Interface Framework (AIF), which is essential for efficiently managing queued RFCs in this cloud environment: The usual technical monitors such as the transactions SMQ1/SMQ2/sbgrfcmon are not allowed in S/4HANA cloud Still, tracking down errors in asynchronous communication requires a monitoring infrastructure: Errors in asynchronous communication scenarios are not realized at the time they occur, but only later when their context is no longer available for analysis.
To overcome these problems, AIF provides an easy way to retrieve and look into the respective payload that might have caused a particular error and to also change parameter values of the respective RFC data transmission, both in onPremise and S/4HANA cloud systems. To profit from these AIF features, you need at least ABAP release 753 oP or 772 in the cloud and mandatory usage of fast serialization: These AIF features require on-demand serialization and de-serialization of the payload, which is only available with fast serialization.
How to Easily Select and Configure Fast Serialization
Using fast serialization is simple and straight forward – no matter if you want to use fast serialization for an existing or for a new RFC scenario. Always start by selecting the button “Fast serialization check” in the change/edit mode (!) of the respective destination in transaction SM59 in the right upper part of the screen, once you have navigated to an existing destination or created a new one. This check tells you
1. If fast serialization is available in the target system and, if so, by default, proposes to select fast serialization.
2. Whether fast serialization should be configured to use LAN or WAN compression for your respective scenario. (This proposal is based on a measurement of the latency between your system and the target system.)
3. Some details of the interface contract to be used for the respective scenario.
While the first two selections are straight forward and easy to understand, some more explanation is needed as to why choosing the right interface contract is important when using fast serialization for existing scenarios and which details of this contract are proposed by the check. As you already know, the interface contract determines, whether the interface check is tolerant or strict, when parameter properties differ between client- and server-side, and the interface contract also defines which parameter extensions are permitted.
If you select “destination for new scenario”, you get a future-proof interface contract with these advantages:
⚫ Maximal extensibility: It is permitted to extend structures and tables in parameters at all positions, not only at the end.
⚫ An error is thrown whenever data is lost due to truncation (which means that S/4HANA mode is implicitly selected for new scenarios)
If you select fast serialization for an existing scenario, S/4HANA mode is proposed (and highly recommended), if at least one communication partner in the respective scenario is on an S/4HANA release, because this mode mitigates problems resulting from field truncation by RFC due to field extensions in DDIC.
Once you confirm the selections made in this dialogue window, they are saved. In case of a new scenario, your configuration is now finished. In case of selecting fast serialization for an existing scenario, you still have to tell the system, which emulation mode you need, which means, whether fast serialization’s interface contract should be compatible with classic serialization or with basXML. This is done under the tab “Special Options” at the bottom under the header “Interface Contract of Fast Serialization”.
As explained above, in RFC scenarios between systems on different releases, RFC parameters may differ in in name, type, or length between client- and server side, or structures in parameters may not have exactly the same components on both sides. In general, RFC does transmit the content of these parameters despite these differences in parameter properties between client and server side. This is why classic serialization and basXML have a loose interface contract and, thus, are pretty robust and tolerant in transmitting parameters, even if there is no perfect fit in the parameters between client and server side. Since, in general, classic serialization tolerates technical differences in parameters that lead to an error in basXML, and vice versa, fast serialization has
⚫ An interface contract that tolerates the same deviances as classic serialization and
⚫ Another contract that emulates basXML behavior.
When using fast serialization for an existing RFC scenario, it is, in general, recommended to select the same interface contract as the serialization that has been used before, because the functioning of your application may depend on the specific tolerance of basXML or classic serialization respectively. Only the appropriate interface contract will ensure that fast serialization’s behavior is compatible with the serialization that has been used before.
If you have also selected S/4HANA mode, the compatibility of the interface contract with the serialization you have chosen will be limited as far as implicit parameter truncation is concerned: Fast serialization will mimic the respective interface contract, with the exception that there will be no implicit, silent parameter truncation as in classic serialization and basXML.
Note: If you chose the basXML emulation mode, you must also decide whether you want just “basXML” (basXML-behavior is chosen, only if basXML is selected both in the destination and the respective RFM) or a behavior like basXML forced, which means that fast serialization mimics basXML’s interface contract, no matter if the basXML flag is also set in the respective RFM or not. In case of doubt, your choice should be based on whether or not “basXML forced” has been selected before in the destination.
Note: Above, it has been mentioned that fast serialization’s emulation of classic serialization and basXML corrects some errors in their interface contracts: In one case, classic serialization is so excessively tolerant that the data transmission may result in meaningless data on the receiver side, in another case, basXML’s behavior is not consistent with the rules of the ABAP compiler. Fast serialization corrects such faulty behavior:
⚫ If the parameter types on client- and server side are very different, classic serialization may create garbled data on the receiver side – that is data which cannot be correctly interpreted and is of no use to anybody – without even throwing an error. Fast serialization handles these situations better:
- If possible, it preserves the content of the data by using ABAP`s rules of implicit type conversion (For example, the character field ‘11’ is converted to an integer with the value “11”, while classic serialization’s transmission of this data results in garbage data.)
- If data loss due to garbled data cannot be prevented, fast serialization throws an error.
⚫ basXML’s type check of character-like fields is stricter than ABAP‘s type check, which leads to the unsatisfactory situation that some meaningful content of character-like fields is fine with the ABAP compiler, but not with basXML: A developer may, for example, quite intentionally use “88888888” in a date field to signify a particular condition, which is tolerated by the ABAP compiler, but not by the basXML parser. Fast serialization avoids inconsistency by correctly transmitting the data under these conditions and thus follows the same rules as the ABAP compiler, which is what developer expect.
No comments:
Post a Comment