It is said that every Belgian is born with a brick in their stomach and wants to build their own house. Having paid a lot of money for a (ever shrinking) building lot, Belgians tend to do a lot of the building work themselves in order to try and keep the mortgage as low as possible. The end result is almost always a half finished trite or country style house due to a lack of money. The garden remains fallow or is a lawn at best. But since everyone always wants to stake out their territory they always try to fence their garden. Proper fencing is expensive which is why a lot of people plant those fast growing conifers, which also have the advantage of preventing people from looking in to one's garden, since the houses are squeezed together like sardines in a tin. It is, or rather was, the same with our house. That is to say that that is what the previous owners did. After 15 years, we found that we had had enough of it and decided to replace these fast growing conifers with proper fencing and to plant a hedge from indigenous plants like the classic hornbeam. Since I'm not exactly a hero when it comes to major garden works I've left the uprooting of the conifers to a pro. My wife also wanted some fruit trees, and since a hawthorn didn't survive its move due to the installation of a A Simulation of Semaphores, I decided to plant a mid sized prune tree. Before that could be done however, the old hawthorn needed to be removed. That went rather smoothly. The problem was cutting the tree in to small enough pieces so that my shredder could handle them. I can tell you that hawthorn wood is rock hard. It didn't go as smoothly as I wished. So I decided to have a go at it with an axe which belonged to my late father. Luckily it was relatively blunt because the axe bounced off for some reason – oh well I admit it, it was my clumsiness – and the axe ended up embedded in my hand doing some carving which would go down well in certain tattoo milieus.
Short IT
I had the same situation in ABAP the other day. For a project I needed to put long texts into an infotype. The long text came from a web application where the user has a text area for providing information. The information provided doesn't have any size limitations. The user can enter his/her memoirs if he/she wants to. This leads to problems when one wants to store this information in the infotype. The standard Function Module for retrieving and storing data from that infotype uses the type TDLINE (132 characters) as type for that long text. That implies that the long text needs to be split into pieces. “Oh, that's easy”, you might say, “just use the SPLIT command”. Alas, this command isn't suitable for this purpose since it would create a record per word. For the above text, this would result in a table with 446 records. That isn't a very economical method of storing. Not from the point of view of storing the text, but if you want to join the records into one text, you would need to loop 446 times in order to achieve it. Needless to say that performance wise this isn't a good idea. You only require 19 records if you can split the text in to pieces of 132 characters. So I started looking for FMs that could solve my problem and the result was:
FORMAT_TEXTLINES
SPLIT_LINE
TEXT_SPLIT
SOTR_SERV_STRING_TO_TABLE
The latter looked the most suitable for doing this. Now that FM has its own peculiar properties. First off it has OTR in it. It is one of the many FMS with that acronym in its name. Only the link to it is a bit vague to me. Honestly, I've a love-hate relationship with OTR. I love the idea of having your texts outside the application in order not to have hassle translating the text. But the implementation of it leaves a lot to be desired, certainly when it comes to long texts. The latter is a real burden to maintain.
And why does one need two transactions to create/maintain the texts: SOTR_EDIT and SE63? It's a bit the same with SM49 and SM69 for external commands, when in my opinion things could be reduced to one single transaction in order to prevent confusion. I guess there must be a good reason for doing it otherwise, but I haven't discovered it (yet).
Back to the SOTR_SERV_STRING_TO_TABLE FM. My attention was drawn by the language parameter. I was hoping that language dependant grammatical rules would be used for splitting long words that don't fit in the record and for splitting text even more economically. I hoped in vain. It just cuts the words in chunks. E.g. If you want to split the word dependant into 5 characters pieces, it'll end up as
depend
ant
whereas I would have expected
depen-
dant
In the first case you can never know whether “depend" and “ant” need to be joined as one word. I thought that I could still count on the space at the end as being not useable. Well, that's not the case. The infotype is the guilty party. Although the update function modules have a TDLINE field, the text is saved in the IT in chunks of +/- 62 characters. On top of that, it doesn't seem to take the spacing into account.
Summing all of this up we need several parameters:
Parameter 1: the string that you want to split into a table
Parameter 2: specify if you want to skip eventual line breaks. This parameter is similar to the parameter in SOTR_SERV_STRING_TO_TABLE.
Parameter 3: indicates whether you want leading spaces on a new line.
E.g.:
This is a line
and the second line starts with a space
or
This is a line
and the second line starts without a space
Parameter 4: indicates the desired record length
Parameter 5: is used when a word is larger than the desired record length. You can specify a sign to indicate that the word is in fact spread over multiple records.
E.g.:
Param 1: Background
Param 4: 4
Param 5: +
Will give as result:
Back
+grou
+nd
One needs to bear in mind that it is best to avoid using hyphens, or any other generally used special character, in order to prevent some words from being concatenated unnecessarily, and to prevent these special symbols, such as hyphens, from being deleted inadvertently.
Parameter 6: is the table containing the result
The source can be downloaded at this place, but I wanted to share the flow logic with you in the form of pseudo code.
If no line breaks
Delete line breaks
Endif.
Determine length of text.
While the length of the text > desired line length
Take a/the next chunk of the text with the size of the desired line length
Determine the place of the last space of that chunk
If no space found
Take a chunk of the size of the desired line length
Else
Take a chunk till the place of that last space
If no starting space is allowed
Skip that space.
Endif
Endif
If word is longer than desired line length and splitting character is defined
Split at the desired line length and insert the splitting character
Endif
Add the line to the table
Endwhile
Add the line to the table
Conclusion
This might not be the most elegant or most scholarly code, that you've ever seen, and there might be better ways to achieve the same result. In this specific case it was the most practical code (that I could think of). I just wanted to share this code with you in case you needed a similar solution. It's up to you whether you use them or not.
