AS_API_READ_V21_2008_en

7/27/2019 AS_API_READ_V21_2008_en

http://slidepdf.com/reader/full/asapireadv212008en 1/17

SAP AG

AS_API_READProgrammed Accesses to the Archive InformationSystem

Version 2.1

September, 2008

7/27/2019 AS_API_READ_V21_2008_en


AS_API_READ – Programmed Accesses to the Archive Information System Version 2.1

©SAP AG, 2008

Copyright

© Copyright 2008 SAP AG. All rights reserved.

No part of this documentation may be reproduced or transmitted in any form or for any purpose without theexpress permission of SAP AG.

SAP AG further does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP AG shall not be liable for any special, indirect, incidental,or consequential damages, including without limitation, lost revenues or lost profits, which may result fromthe use of these materials. The information in this documentation is subject to change without notice anddoes not represent a commitment on the part of SAP AG in the future.

Some software products marketed by SAP AG and its distributors contain proprietary software componentsof other software vendors.

Microsoft®, WINDOWS®, NT® and EXCEL® and SQL-Server® are registered trademarks of MicrosoftCorporation.

IBM®, OS/2®, DB2/6000®, AIX®, OS/400® and AS/400® are a registered trademark of IBM Corporation.

OSF/Motif® is a registered trademark of Open Software Foundation.

ORACLE® is a registered trademark of ORACLE Corporation, California, USA.

INFORMIX®-OnLine for SAP is a registered trademark of Informix Software Incorporated.

UNIX® and X/Open® are registered trademarks of SCO Santa Cruz Operation.

ADABAS® is a registered trademark of Software AG.

SAP, the SAP logo, mySAP.com, R/2®, R/3®, RIVA®, ABAP/4®, SAPoffice®, SAPmail®, SAPaccess®,SAP-EDI®, SAP ArchiveLink®, SAP EarlyWatch®, SAP Business Workflow®, R/3 Retail® are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world.

SAP AG assumes no responsibility for errors or omissions in these materials.

All rights reserved.

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

History

Version Date Sections Changed

1.0 Nov. 12, 2002

1.1 Feb. 12, 2003

1.2 Mar. 12, 2003 6.7

1.3 Apr. 1, 2003 Consolidation of several different versions

2.0 Oct. 22, 2003 Complete revision for internal use

2.1 Dec. 5, 2003 Footnote about database indexes

2.1 Sep 2, 2008 No changes in content, but guide is stillapplicable for SAP NetWeaver 7.0 andabove

Symbols Used

Symbol Meaning

Note

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

Contents

1 What is the purpose of this document? .......................................................................5

2 Quickstart (example from the appl ication)...................................................................5

3 Interface ..........................................................................................................................6

3.1 I_FIELDCAT: Field Catalog (importing, obligatory) .............................................................................6

3.2 I_SELECTIONS: Selections (importing, obligatory).............................................................................6

3.3 I_OBLIGATORY_FIELDS: Required Fields (importing, opt ional) ........................................................7

3.4 E_RESULT: Result of Selection (exporting).........................................................................................7

3.5 Exceptions .............................................................................................................................................7

4 How infostructures are determined ..............................................................................8

5 Examples.........................................................................................................................8

5.1 How obligatory fields are defined.........................................................................................................9

5.2 Complex selections in the format RSDS_FRANGE_T..........................................................................9

5.3 Making selections using tables ..........................................................................................................10

5.4 More than just arch ive fil e and offset .................................................................................................10

6 FAQ and common errors .............................................................................................10

6.1 Making select ions using one field ......................................................................................................11

6.2 Unstructured results ...........................................................................................................................11

6.3 Testing environment for function modules (in SE37)........................................................................12

6.4 Several infostructures for one field catalog.......................................................................................12

6.5 Several field catalogs ..........................................................................................................................12

6.5.1 Reading via several field catalogs .....................................................................................................13

6.5.2 Obsolete field catalogs......................................................................................................................13

6.5.3 Choosing the “right” field catalogs .....................................................................................................13

6.6 Customer-speci fic field catalogs ........................................................................................................13

6.7 Long Selection Fields..........................................................................................................................14

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

1 What is the purpose of this document?

This document describes the capabilities of the function module AS_API_READ, which can be used toaccess the data in the Archive Information System (AS). To access data in AS, selection criteria aretransferred to the module, and the module then fetches the requested data from an archive informationstructure and returns it. This data is largely comprised of an archive file and an offset, which is why thefunction module AS_API_READ can be used to access archived data with the support of an index.

This, for example, will enable the user to quickly and automatically access data in the archive, within anapplication or a customer-specific solution.

1If this interface to the AS did not exist, new index solutions would

have to be developed to access the archive2. The function module AS_API_READ itself does not carry out

any archive accesses. It merely determines where in the archive a specific data object resides. The actualaccess to the archive is carried out via the normal ADK functions (ARCHIVE_READ_OBJECT, ARCHIVE_GET_TABLE, etc.).

In theory, it would be possible to access the tables of the AS (ZARIX-tables) directly. However, this is notvery desirable, because this is part of AS implementation, which may change in the future. In addition, thenames of infostructures should not be hard-coded into the call of the function module, because the option of creating one’s own infostructures is meant to provide a certain flexibility. Instead, only the name of the fieldcatalog is used in the coding.

2 Quickstart (example from the application)

Below we will use a simple example to show how the function module AS_API_READ is used. In thisexample, the user wants to call up data objects with flight bookings of smoking passengers, on September 9,1998. The example builds on the following field catalog:

Based on this field catalog, the following coding would be used:

DATA: BEGI N OF g_sbook,smoker LI KE sbook- smoker ,f l dat e LI KE sbook-f l dat e,

END OF g_sbook,gt_r esul t TYPE TABLE OF ai nd_arkey.

g_sbook- smoker = ' X' .g_sbook- f l date = ' 19980907' .

CALL FUNCTI ON ' AS_API _READ'EXPORTI NG

i _f i el dcat = ' DEMO_SBOOK'i _sel ect i ons = g_sbook

1To be able to implement a quick data access, you might need a database index for the infostructure used. For more information about

this topic see the WEB AS 640 documentation on the Archive Information Structure under Using the Archive Information System ->

Creating Database Indexes, or SAP Note 164704.2

These kinds of solutions have in fact been developed. However, the Archive Information System is so established by now, that other

indexing programs should not be used anymore.

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

I MPORTI NGe_resul t = gt _resul t [ ] .

This fragment of coding can be explained as follows:

Find an infostructure that matches the field catalog DEMO_SBOOK.

In this infostructure, find all records with SMOKER = ‘X’ and FLDATE = ‘19980907’.

Send back the archive file and the offset of the records that were found.

This type of access is usually sufficient for single object accesses, such as searching for documents whenthe document number is known.

3 Interface

3.1 I_FIELDCAT: Field Catalog (import ing, obligatory)

In order for the system to be able to read the data, a field catalog has to be specified. The field catalog

defines the selection method. The function module searches for active infostructures for the specified fieldcatalog. If several infostructures exist for this field catalog, the infostructure that best fulfills certain rules (seebelow for more detail) will be picked.

It is not possible to have an already specified, fixed infostructure. This is because the field catalogs arespecified by the developer of the archiving object (generally SAP), while the infostructures are created duringthe configuration of the Archive Information System. This flexibility would be affected if infostructures werehard coded.

3.2 I_SELECTIONS: Select ions (import ing, obl igatory)

In this section you enter the values the system should search for. Depending on your requirements, you canenter simple or complex search criteria in three different formats:

1. Selections in the format of type RSDS_FRANGE_T . This is a table with field names and thecorresponding selection options (“Ranges” or “Select Options”).

Every field specified in the selections has to be a field of the field catalog, meaning that the fields of thefield catalog must have the same names as those entered in the selections. If this is not the case, thenthe exception FIELD_MISSING_IN_FIELDCAT will be triggered.

Here, the archive file (field name ARCHIVEKEY) and the offset (ARCHIVEOFS) are also available asselection fields.

For the selection carried out by the function module only those fields are used that are actually includedin the selected infostructure. (If there is any doubt, the system chooses the infostructure that contains asmany selection fields as possible). In an extreme case, none of the selection fields will be contained inthe infostructure; then all (!) entries in the infostructure will be pulled. This can be avoided, for example,by using the parameter I_OBLIGATORY_FIELDS.

2. A structure. It is also possible to specify a structure for your selection, but you should keep in mind thatonly actual structures will work in this case. For example, it is not possible to specify a single field. Youcan use the following data objects, among others:DATA: BEGI N OF g_sel ect i ons1,

smoker LI KE sbook- smoker ,f l dat e LI KE sbook- f l dat e,

END OF g_sel ect i ons1.

DATA: g_sel ect i ons2 TYPE sbook.

In this case, all the fields that are not empty in the structure (meaning the fields that do not contain thedata type-specific initial value) and that appear in the field catalog, are considered to be selection fields.

Of course, ultimately the selection process only uses the fields that are contained in the infostructure.

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

However, it may be the total number of selection fields that will determine which infostructure the systemdecides to use.

The function module will bring up all the entries that have the same values in the selection fields. For selection fields that do not appear in the infostructure the same applies as in selections of typeRSDS_FRANGE_T.

3. A table whose row structure is like the structure in 2. In general, if you use this method, you will get thesame results as if you called up the function module AS_API_READ separately for every row in thetable, and combined the results.

If the system recognizes that data different from the data described here was specified, it will trigger theexception PARAMETERS_INVALID. However, the system may not recognize some error situations, whichcan lead to unexpected results. We, therefore, recommend that you carefully check and test the use of theparameter I_SELECTIONS.

3.3 I_OBLIGATORY_FIELDS: Required Fields (import ing, optional)

This parameter can contain a table of field names that have to appear in the selected infostructure. Theparameter type should be a table of the type FIELDNAME.

If there is no active infostructure that contains the required entry fields, the exceptionNO_INFOSTRUC_FOUND is triggered. The standard contains no obligatory fields. Because of this, youmay run the risk that all entries in the infostructure will be read. We, therefore, recommend that you use thisparameter or that you make sure the selections contain fields which you know are contained in theinfostructure.

3.4 E_RESULT: Result of Selection (exporting)

In E_RESULT the result of the selection is delivered. You have to specify an internal table whose rows haveto be structured. The rows have to contain at least one field from the field catalog or the field ARCHIVEKEY.(If the structure contains the field ARCHIVEOFS, then ARCHIVEKEY has to be there, also).

Besides those fields, the rows of the structure may contain any other fields. The system fills the table as if aMOVE-CORRESPONDING would take place from the infostructure into the table rows. In other words, thefields of the table that have the same name as the fields in the infostructure are filled. This is also true for thefields ARCHIVEKEY and ARCHIVEOFS, if they are contained in E_RESULT. Here you may use particularlythe following table to get the result:

DATA: gt _r esul t TYPE TABLE OF ai nd_arkey.

This is how you obtain pointers to the corresponding data objects in the archive.

3.5 Exceptions

PARAMETERS_INVALID

This exception is triggered if one of the parameters is erroneous or the parameters do not match. Below welist some examples of this:

The field catalog was not found.

The selection fields are contained in the field catalog. (In certain cases this exception appearsinstead of FIELD_MISSING_IN_FIELDCAT.)

The data type of I_SELECTIONS or E_RESULT could not be determined or is unsuitable.

NO_INFOSTRUC_FOUND

This exception is triggered if no active infostructure could be found for the field catalog or none of the

infostructures have all of the obligatory fields (I_OBLIGATORY_FIELDS).

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

FIELD_MISSING_IN_FIELDCAT

This exception is triggered if a field from the selection criteria (I_SELECTIONS) or the obligatory fields(I_OBLIGATORY_FIELDS) is not contained in the field catalog.

4 How infostructures are determinedIt is not possible to enter the infostructure directly with the function module AS_API_READ. It is only possibleto enter the field catalog. The idea behind this is that field catalogs should be created only by thedevelopment, so that when you specify a field catalog, the semantics of the fields are reliable. During theconfiguration of the Archive Information System it is then possible to create infostructures for these fieldcatalogs. The self-created infostructures contain user-specific fields (in contrast to the standardinfostructures) or they have specific database indexes that enable users to make rapid accesses via specificfields.

Usually only one infostructure will be used productively for a field catalog, which is why the choice of whichinfostructure to use is rather academic. Nevertheless, it may occur, especially during development or the testphase, that there are several infostructures that are filled to differing degrees. In this case the function

module AS_API_READ will often unexpectedly choose the infostructure that does not contain the desireddata. Because this process is somewhat confusing, we will describe in more detail how infostructures aredetermined:

1. The system finds all the active infostructures for a given field catalog (I_FIELDCAT). If no suchinfostructure exists, the exception NO_INFOSTRUC_FOUND is triggered.

2. If information was transferred with the parameter I_OBLIGATORY_FIELDS, then the system onlyconsiders those infostructures that contain all the obligatory fields. If no such infostructure exists, theexception NO_INFOSTRUC_FOUND is triggered.

From this point on the system will be able to find a corresponding infostructure. However, there may beseveral infostructures to choose from, and the right infostructure will have to be picked.

3. The system will only consider those infostructures that contain the maximum number of selection fields.

(The selection fields are those fields from I_SELECTIONS that are also contained in the field catalog).4. If there are still several valid infostructures to choose from, then the system will only consider those with

the most result fields. (Result fields are those fields that appear in E_RESULT and in the field catalog).

5. If there is still more than one infostructure for the system to choose from, then the system evaluates theselection fields according to the order in which they appear in I_SELECTIONS. Infostructures thatcontain the first selection field are considered to be more “fitting” than those that do not contain the firstfield, etc.

6. If, however, there is still more than one infostructure to choose from, then these are probably very similar in terms of their structures. In this case the system picks an infostructure at random.

The system picks the infostructure purely based on rules. The number of entries or other suchfactors is not taken into account during the process. Also, the system always reads only from oneinfostructure, even if there are several that would be appropriate. (The system does not combine theset of hits in any way).

5 Examples

Below we elaborate on the above-named variations, using coding examples. As in the previous examples,these are based on the following field catalog:

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

5.1 How obligatory fields are defined

DATA: BEGI N OF g_sbook,smoker LI KE sbook- smoker ,f l dat e LI KE sbook-f l dat e,

END OF g_sbook,gt_r esul t TYPE TABLE OF ai nd_arkey,gt _obl f i el ds TYPE TABLE OF ai nd_dst f .

g_sbook- smoker = ' X' .

g_sbook- f l date = ' 19980907' .APPEND ' FLDATE' TO gt _obl f i el ds.

CALL FUNCTI ON ' AS_API _READ' .EXPORTI NG

i _f i el dcat = ' DEMO_SBOOK'i _sel ect i ons = g_sbooki _obl i gat ory_f i el ds = gt _obl f i el ds

I MPORTI NGe_r esul t = gt _r esul t [ ]

EXCEPTI ONSno_i nf ost r uc_f ound = 1.

Only infostructures that contain the field FLDATE are taken into account. If for the field catalogDEMO_SBOOK, the system cannot find an active infostructure containing the field FLDATE, then the

exception NO_INFOSTRUC_FOUND is triggered.

5.2 Complex selections in the format RSDS_FRANGE_T

TYPE-POOLS: r sds.

DATA: g_sel ect i ons TYPE r sds_f r ange_t ,gt_r esul t TYPE TABLE OF ai nd_arkey.

* G_SELECTI ONS mi t Sel ekt i onsbedi ngungen f ül l en[ . . . ]


i _f i el dcat = ' DEMO_SBOOK'i _sel ecti ons = g_sel ecti ons


This procedure makes it possible to use practically any SELECT-OPTIONS to make selections. To do this,the data object G_SELECTIONS has to be filled accordingly with the names of the selection fields and thecorresponding ranges. This procedure is especially useful for the selection criteria of reports.

You should keep in mind, however, that not all selection criteria of the report can be transferred to thefunction module AS_API_READ. Only those selection criteria can be transferred, whose fields are containedin the field catalog. If this is not the case, you will get the exception FIELD_MISSING_IN_FIELDCAT.Generally the fields contained in a field catalog should be known. If you are not sure about the fields, youcan find out what the possible selection fields are via the function module AS_API_INFOSTRUC_FIND.

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

5.3 Making selections using tables

TYPES: BEGI N OF t y_sbook,f l dat e LI KE sbook-f l dat e,

END OF t y_sbook.

DATA: g_sbook TYPE t y_sbook,

gt _sbook TYPE TABLE OF t y_sbook,gt_r esul t TYPE TABLE OF ai nd_arkey.

g_sbook- f l date = ' 19980907' .APPEND g_sbook TO gt _sbook.g_sbook- f l date = ' 19980906' .APPEND g_sbook TO gt _sbook.


i _f i el dcat = ' DEMO_SBOOK'i _sel ect i ons = gt _sbook


This selection option is similar to making selections using the individual rows of the table and combining theresults at the end. In other words, this selection will deliver all the entries for which FLDATE = ‘19980907’ or FLDATE = ‘19980906’.

Note on performance: Generally a complex selection is quicker than making selections via a table.

5.4 More than just archive file and offset

TYPES: BEGI N OF t y_r esul t .I NCLUDE STRUCTURE sbook.I NCLUDE STRUCTURE ai nd_ar key.

TYPES: END OF t y_r esul t .

DATA: BEGI N OF g_sbook,f l dat e LI KE sbook-f l dat e,

END OF g_sbook,gt _r esul t TYPE TABLE OF t y_r esul t .

g_sbook- f l date = ' 19980907' .


i _f i el dcat = ' DEMO_SBOOK'i _sel ect i ons = g_sbook


In this example the fields ARCHIVEKEY and ARCHIVEOFS in the table GT_RESULT are filled, but also allthe fields that appear in the infostructure and in SBOOK. However, note that for the person calling up thedata it is usually difficult to decide why a field remains empty - it can be empty either because it is notcontained in the infostructure, or because it is contained in the infostructure, but is, nevertheless, empty.

6 FAQ and common errors

In the following section we discuss common questions and errors that have arisen when the function module AS_API_READ was used.

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

6.1 Making selections using one field

The following coding example is incorrect:DATA: g_vbel n LI KE vbak- vbel n,

gt_r esul t TYPE TABLE OF ai nd_arkey.g_vbel n = ' 123' .


i _f i el dcat = ' DEMO_VBAK'i _sel ect i ons = g_vbel n


It may occur that using the coding in this example will lead to correct results, because the function moduledoes not understand this situation and as a result will deliver all the entries in an infostructure. Often timesthis is followed by a filtering of the data using the actual archived data.

The following coding example would deliver the correct results:DATA: g_vbak TYPE vbak,

gt_r esul t TYPE TABLE OF ai nd_arkey.

g_vbak- vbel n = ' 123' .


i _f i el dcat = ' DEMO_VBAK'i _sel ect i ons = g_vbak


This problem can also arise in a slightly different format, when a table is used as the selection criteria.DATA: gt_vbel n TYPE TABLE OF vbak- vbel n,

gt_r esul t TYPE TABLE OF ai nd_arkey.APPEND ' 123' TO gt_vbel n.

APPEND ' 456' TO gt_vbel n.


i _f i el dcat = ' DEMO_VBAK'i _sel ect i ons = gt _vbel n


The following coding example would deliver the correct results:DATA: gt _vbak TYPE TABLE OF vbak,

gt_r esul t TYPE TABLE OF ai nd_arkey.FI ELD- SYMBOLS: <g_vbak> TYPE vbak.APPEND I NI TI AL LI NE TO gt _vbak ASSI GNI NG <g_vbak>.<g_vbak>- vbel n = ' 123' .APPEND I NI TI AL LI NE TO gt _vbak ASSI GNI NG <g_vbak>.<g_vbak>- vbel n = ' 456' .


i _f i el dcat = ' DEMO_VBAK'i _sel ect i ons = gt _vbak


6.2 Unstructured results

You may encounter a similar problem in the results table. The rows of the table actually have to contain

fields. The following example for finding archive files that contain a specific document, is incorrect:

correct

incorrect

correct

incorrect

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

DATA: g_vbak LI KE vbak.gt_r esul t TYPE TABLE OF archi vekey.



i _f i el dcat = ' DEMO_VBAK'

i _sel ect i ons = g_vbel nI MPORTI NG

e_resul t = gt _resul t [ ] .

The following coding example would deliver the correct results: TYPES: BEGI N OF t y_r esul t ,

archi vekey TYPE arkey,END OF t y_r esul t .

DATA: g_vbak TYPE vbak.gt _r esul t TYPE TABLE OF t y_r esul t .



i _f i el dcat = ' DEMO_VBAK'i _sel ect i ons = g_vbak


6.3 Testing environment for funct ion modules (in SE37)

Because the function module AS_API_READ has generic parameters (the data type of the parameter is notspecified), it cannot be tested in the testing environment for function modules (SE37 “Execute”). This isnot an error of the function module, but rather it could be attributed to a weakness of the testing environment.Therefore, if you want to test this function module, you must write a program to do so.

6.4 Several infostructures for one field catalogIt is often the case, that the function module AS_API_READ produces unexpected results duringdevelopment. Frequently, this is because the field catalog that was used has several infostructures, of whichsome are not filled or that are in some other way problematic. Therefore, to test the function module, werecommend that you first deactivate all the infostructures for the field catalog and then activate only thosethat you want to test. Either way, a production system will generally only have one infostructure per fieldcatalog.

6.5 Several field catalogs

For some archiving objects SAP delivers several different field catalogs. There are various reasons for this:

1. The archived data objects consist of one entry from a header table and several entries from an itemstable. An example of this is the archiving object SD_VBAK and the tables VBAK and VBAP. Some usersmay want to access the data rapidly via fields that are contained in the items table (such as VBAP-MATNR). For this, an infostructure has to have approximately as many entries as archived entries of theitem table. Others only need the fields of the header entries. In the latter case, if the program only hadone field catalog, either selections via the fields of the items table would not be possible, or the resultwould be a waste of storage space. This is why SD_VBAK, for example, has the field catalogsSAP_SD_VBAK_001 (only header fields) and SAP_SD_VBAK_002 (additional items fields).

2. For some archiving objects, field catalogs were pre-delivered (via SAPSERV-Transport) or the fieldcatalogs were changed and are now incompatible with prior versions. As a result, sometimes there aretwo field catalogs that more or less have the same functionality. For example, a given system may havethe field catalogs SAP_SD_VBAK_001 and SAP_SD_VBAK_901, which basically look the same.

3. It could be that one data object contains several partial objects of connected applications. When aproduction order (archiving object PP_ORDER) is archived, generally cost accounting line items are also

correct

incorrect

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

archived. In order to be able to display the documents of these line items, you need a field catalog thatcontains the cost accounting document number. If, for your search for the production order, you were tomix the two field catalogs (if such a thing could be achieved, technically speaking), an enormous amountof data would be produced in the infostructures. For this reason you have the field catalogsSAP_PP_ORDER001 and SAP_COBK_PPOR01.

How to deal with several existing field catalogs using AS_API_READ depends on which of the above-named

situations you are facing. We will discuss this further in the following section.

6.5.1 Reading via several field catalogs

If there are two or more field catalogs whose infostructures contain the desired data, then follow theprocedure shown in the following coding example. In this coding fragment, the system first checks the firstfield catalog. If it finds no infostructure for this field catalog it will use the second field catalog.DATA: g_vbak LI KE vbak,

gt_r esul t TYPE TABLE OF ai nd_arkey.

g_vbak- vbel n = vbel n.CALL FUNCTI ON ' AS_API _READ'

EXPORTI NG

i _f i el dcat = ' SAP_SD_VBAK_001'i _sel ect i ons = g_vbak


EXCEPTI ONSno_i nf ost r uc_f ound = 2.

I F NOT sy- subr c I S I NI TI AL.CALL FUNCTI ON ' AS_API _READ'

EXPORTI NGi _f i el dcat = ' SAP_SD_VBAK_002'i _sel ect i ons = g_vbak


EXCEPTI ONS

no_i nf ost r uc_f ound = 0.ENDI F.

This procedure is especially helpful for the first case described above. It is also possible to read from bothfield catalogs and combine the results at the end. However, most live systems will only have an activeinfostructure for one of the two field catalogs, or the infostructures have been built for the same archive files.

This procedure will only work, if the selection criteria used make sense for both field catalogs.

6.5.2 Obsolete field catalogs

In the second of the above-mentioned cases there is an “old” and a “new” field catalog. It is possible to readdata using both field catalogs, as previously described. However, it is usually better to work with the newer field catalog and to let the old one become obsolete. Switching to the new field catalog may represent some

extra efforts. However, in the long term this switch proves to be beneficial for both development, becauseprograms would become easier, and for users and administrators.

6.5.3 Choosing the “ right” field catalogs

In the last of the above-mentioned cases, in which one archiving object had several field catalogs that fulfilldifferent requirements, no problems should arise. Generally, it is clear which field catalog should be used,and the dilemma of having several field catalogs to choose from does not arise.

6.6 Customer-specific field catalogs

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

This section is not relevant for customer-specific read programs in which the system accesses the Archive Information System. For those read programs with customer-specific field catalogs, thesame rules apply as those we described above for SAP field catalogs.

There are different reasons for why there are also customer-specific field catalogs. For example, somecustomers have special requirements, or the tables contain customer-specific tables that cannot becontained in the field catalogs delivered by SAP. In principle it would be possible to also include customer-

specific field catalogs in the evaluations performed by SAP standard programs. However, this is notrecommended, because of the following reasons:

The names of customer-specific field catalogs cannot be hard-coded into standard programs,because they are not known yet during development. Because of this, the system would have toaccess the system tables of the AS; however, these tables do not belong to the official AS interface.

The semantics of customer-specific field catalogs may not fit into the standard SAP coding, becausesome of the fields could have names that the program does not expect, or the fields used by theprogram mean something unexpected in the customer-specific field catalog.

Through tests, SAP makes sure that the SAP field catalogs are compatible with the standardprograms. Customer-specific field catalogs used in standard programs often lead to problems.

6.7 Long Selection Fields

In this document we have explained that data objects of the type RSDS_FRANGE_T as well as general (flat)structures and tables can be transferred to the parameter I_SELECTIONS. The function module internallyconverts all selection criteria into the same format. In this format, however, the length of the fields that canbe saved is limited. The fields can either be up to 45 or up to 100 characters long, depending on whether or not the changes from SAP Note 593627 have already been implemented

3. If selection fields that contain

more than 45 characters, or more than 100 characters, are used, it may occur that the function module AS_API_READ will deliver erroneous results.

Below we describe the different ways you can deal with selection fields that contain more than 45 characters,depending on the SAP R/3 or SAP Web AS releases, and the different available selection options. For fieldsthat contain 45 or fewer characters nothing has changed.

SAP Web AS 6.40 and higher

In SAP Web AS 6.40 the maximum length of selection fields was increased to 100 characters4. However, in

this case it does not matter how long the field actually is, but with how many characters it has been filled. If aselection field is filled with more than 100 characters, the function module AS_API_READ will deliver theexception PARAMETER_INVALID.

Selection using a structure or a table with a maximum of 100 characters

If you make the selection using your own structure or table, as in the example shown in Part 2 “ Quickstart(example from the application)“ of this document, you can proceed as before, as long as none of the fieldsare filled beyond the 100-character limit.

Selection using a structure or table with more than 100 characters

It is not possible to transfer a selection field from a structure or a table, if the field has been filled beyond the100-character limit. If it is, you will always receive the exception PARAMETERS_INVALID. In these casesfollow the procedure described under “Selection using ranges greater than 100 characters”.

Selection using ranges up to 100 characters

4For Systems running SAP Web AS 6.40 or higher, these changes are already installed. In SAP Web AS 6.20 the changes are

contained in Support Package 20. For all other releases check SAP Note 593627 to find out as of when the changes are available.

5 Perhaps this may seem to be rather short-sighted. However, 98% of all table fields in SAP R/3 Enterprise have a length of 100characters or less. Moreover, the way the APIs of the Archive Information System handle selections was changed in such a way, thatfurther enlarging the fields, if necessary, would be no problem.

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

As of SAP Web AS 6.40, the function module AS_API_READ can handle selections that contain fields withup to 100 characters. However, the type RSDS_FRANGE_T can no longer be used. You must define your own data type, by following the steps in the example below:

TYPES: BEGI N OF t y_sel opt ,si gn TYPE c LENGTH 1,

opt i on TYPE c LENGTH 2,l ow TYPE c LENGTH 100,hi gh TYPE c LENGTH 100,

END OF t y_sel opt ,BEGI N OF t y_f r ange,

f i el dname TYPE f i el dname,sel opt _t TYPE STANDARD TABLE OF t y_sel opt

WI TH DEFAULT KEY,END OF t y_f r ange.

DATA: gt_f r ange TYPE TABLE OF t y_f r ange,gt_r esul t TYPE TABLE OF ai nd_arkey.

FI ELD- SYMBOLS: <g_f r ange> TYPE t y_f r ange,<g_sel opt > TYPE t y_sel opt .

APPEND I NI TI AL LI NE TO gt_f r ange ASSI GNI NG <g_f r ange>.<g_f r ange>- f i el dname = ' OBJ KEY' .APPEND I NI TI AL LI NE TO <g_f r ange>- sel opt _t ASSI GNI NG <g_sel opt >.<g_sel opt >- si gn = ' I ' .<g_sel opt >- opt i on = ' EQ' .<g_sel opt >- l ow+99 = ' X' .


i _f i el dcat = ' SAP_AS_TEST_001'i _sel ect i ons = gt _f r ange[ ]

I MPORTI NGe_r esul t = gt _r esul t .

Selection using ranges greater than 100 characters

If the value to be used to make the selection definitely contains more than 100 characters, then you must usea different procedure to deal with the fields, as shown in the following example:

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG, 2008

TYPES: BEGI N OF t y_sel opt ,si gn TYPE c LENGTH 1,opt i on TYPE c LENGTH 2,l ow TYPE c LENGTH 100,hi gh TYPE c LENGTH 100,

END OF t y_sel opt ,BEGI N OF t y_f r ange,

f i el dname TYPE f i el dname,sel opt _t TYPE STANDARD TABLE OF t y_sel opt

WI TH DEFAULT KEY,END OF t y_f r ange.

DATA: g_sel val ue TYPE c LENGTH 135,gt_f r ange TYPE TABLE OF t y_f r ange,gt_r esul t TYPE TABLE OF ai nd_arkey.

FI ELD- SYMBOLS: <g_f r ange> TYPE t y_f r ange,<g_sel opt > TYPE t y_sel opt .

PERFORM somethi ng_f i l l i ng_sel val ue CHANGI NG g_sel val ue.

APPEND I NI TI AL LI NE TO gt_f r ange ASSI GNI NG <g_f r ange>.

<g_f r ange>- f i el dname = ' OBJ KEY' .APPEND I NI TI AL LI NE TO <g_f r ange>- sel opt _t ASSI GNI NG <g_sel opt >.<g_sel opt >- si gn = ' I ' .I F STRLEN( g_sel val ue ) <= 100.

<g_sel opt >- opt i on = ' EQ' .<g_sel opt >- l ow = g_sel val ue( 100) .

ELSE.<g_sel opt >- opt i on = ' CP' .<g_sel opt >- l ow = g_sel val ue( 99).<g_sel opt >- l ow+99( 1) = ' *' .

ENDI F.


i _f i el dcat = ' SAP_AS_TEST_001'

i _sel ect i ons = gt _f r ange[ ]I MPORTI NG

e_r esul t = gt _r esul t .

Here you need to keep in mind that GT_RESULT may also contain data objects for which only the first 99characters correspond to the selection value. If after calling AS_API_READ data will be read from thearchive anyway, then the data from the archive should be filtered. Another possibility would be to include theselection field in the results structure (GT_RESULT). Then the field will be filled with the corresponding data,even if it contains more than 100 characters. After that you can take the corresponding lines out of theresults list.

SAP R/3 4.6B to SAP Web AS 6.20

For Releases SAP R/3 4.6B to SAP Web AS 6.20, you can incorporate SAP Note 593627, or the necessarysupport package, and proceed exactly as described under SAP Web AS 6.40. Otherwise proceed as in thedescription for Releases lower than SAP R/3 4.6B.

Release lower than SAP R/3 4.6B

For Releases lower than SAP R/3 4.6B the character limit for a field is still 45. Moreover, it is not possible touse user-defined data types instead of RSDS_FRANGE_T. If a selection field could be filled by more than 45characters, then proceed as in the following coding example:

7/27/2019 AS_API_READ_V21_2008_en



©SAP AG 2008 P 17

DATA: g_sel val ue TYPE c LENGTH 135,gt _f r ange TYPE r sds_f r ange_t ,gt_r esul t TYPE TABLE OF ai nd_arkey.

ai nd_ar key,FI ELD- SYMBOLS: <g_f r ange>g_f r ange TYPE r sds_f r ange,

<g_sel opt >g_sel opt TYPE r sdssel opt .

PERFORM somethi ng_f i l l i ng_sel val ue CHANGI NG g_sel val ue.

APPEND I NI TI AL LI NE TO gt_f r ange ASSI GNI NG <g_f r ange>.<g_f r ange>- f i el dnameg_f r ange- f i el dname = ' OBJ KEY' .APPEND I NI TI AL LI NE TO <g_f r ange>- sel opt _t ASSI GNI NG <g_sel opt >.<g_sel opt >- si gng_sel opt - si gn = ' I ' .I F STRLEN( g_sel val ue ) <= 45.

<g_sel opt >- opt i ong_sel opt - opt i on = ' EQ' .<g_sel opt >- l owg_sel opt - l ow = g_sel val ue( 45) .

ELSE.<g_sel opt >- opt i ong_sel opt - opt i on = ' CP' .<g_sel opt >- l owg_sel opt - l ow = g_sel val ue( 44) .<g_sel opt >- l ow+44( 1) g_sel opt - l ow+44( 1) = ' *' .

ENDI F.

APPEND g_sel opt TO g_f r ange- sel opt _t .APPEND g_f r ange TO gt_f r ange.


i _f i el dcat = ' SAP_AS_TEST_001'i _sel ect i ons = gt _f r ange[ ]

I MPORTI NGe_r esul t = gt _r esul t .

Here you must keep the above-mentioned points in mind. You may find data objects in GT_RANGE thatonly correspond to the first 44 characters of your selection value. In this case you must subsequently filter the information, either from the archive or with the help of an additional field in GT_RESULT.

AS_API_READ_V21_2008_en

Documents

Transcript of AS_API_READ_V21_2008_en