cancel
Showing results for 
Search instead for 
Did you mean: 

OData service for long texts (READ_TEXT)?

Jelena
Active Contributor

We need to provide an OData service for the long texts of a document. These texts are stored in STXH/STXL and are accessed by READ_TEXT FM and similar. We are working with S/4HANA 2020 system and ABAP RAP model (well, trying to, at least).

Using CDS views, the only option to provide these texts is to use a virtual element, as explained here and here. All is well but there is max length of 1033 characters in CDS string. We are dealing with some very long texts, unfortunately, that will exceed that.

Question: in 2022, how do we resolve this? Should we forget about CDS views and just use completely custom implementation in SEGW? Is there any other option? Splitting text into several variables or separate records would be undesirable.

Edit: this scenario does not involve SAP Fiori / UI5, so we don't care for CDS advantages in this area.

Thank you!

VijayCR
Active Contributor
0 Kudos

Hi Jelena ,

Can you reuse the logic similar to the Service SGBT_NTE_CDS_API_D_SRV with 1:N relationship so that you can all the texts for the same ?

Thanks

Vijay

rchudziak
Participant
0 Kudos

In S/4 2020 I noticed there is a CDS view I_Text_Templates which has an association I_TextObjectPlainLongText which selects from table ESH_SR_LTXT (Replicated Plain Longtext) - have a look if it helps

Jelena
Active Contributor
0 Kudos

Hi radek_c ! This specific CDS view is meant for the search and it will have the same problem of 1033 characters string length limitation that is mentioned in my post.

View Entire Topic
former_member185511
Active Participant

Some CDS limits like the above one and the total 4096 char limit is really problematic sometimes. For your scenario, I think just resolving on ABAP layer in a service would contain less moving part. I like doing everything with CDS but some limitations and workarounds to that limitations are creating technical dept. I think keeping simple with a SEGW custom implementation would be cleaner and leaner.