ABAP REPORTS: 2008

Get better Performance of Data Warehouse

A data warehouse has several characteristics-dimensions-responsible for its performance. Often only one dimension contributes to poor data warehouse performance. It may be , narrow network bandwidth causes delays in moving data from transaction systems as well as delivering information to end users while data transformation and end-user query execution are not performance issues. To end users, poor network bandwidth is perceived as poor data warehouse performance.

The following figure shows characteristics of a high-performance data warehouse. It shows that this data warehouse supports a large number of users. Most users issue less complex queries without any performance issues and have a low data warehouse operations/maintenance time requirement, making this data warehouse highly available. Under this environment, everyone is satisfied with the data warehouse performance. In reality, this seldom happens.

The number of users, is not a good indication of data warehouse performance. One hundred users may be issuing simple queries and not have a problem until one analyst starts a complex analytical job that virtually joins a large number of tables to do complex sales trend analysis. This exercise will probably block the data warehouse server for hours. Data warehouse architects must design governing features to control such runaway resource-consuming processes during peak hours.

The consequence of not having complete order operation information in the data warehouse is that the planning, finance, sales, and marketing organizations will not have a full view of corporate operations, such as product inventories and what to stock to fulfill consumers' demands.

The performance issue here is that extracting complete data sets from OLTP and loading that information in a data warehouse all in one step can consume significant OLTP and data warehouse resources, such as the locking up of source and target data objects, network bandwidth, and CPU/memory usage.

Solution is to keep the data extraction process out of the daily OLTP maintenance operation and break down large data extraction processes into multiple tasks. Each task is scheduled several times during regular OLTP business operations to extract and move new data in the data warehouse in an operational data store. Then refresh the data warehouse once or twice a day by combining all incremental data sets from the operational data store without touching the OLTP systems. (1.4)

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

How to Construct Data Warehouse

The previous post of the blog deals with the basic components of Data ware housing. Here we are going to see the technical issues that have to be taken cared while designing the data warehouse.

Global Information Delivery

The Internet and intranets are the primary vehicles for information delivery. There must be robustness (scalability, security, reliability, and cost) of Web services needed to deliver information to end users. It is critical that such Web services provide seamless integration and provide similar development/management environments with the rest of the data objects in all data warehouse layers.

Global Catalog

Global catalog goes hand in hand with the information delivery services. It is hard to find what you need because catalogs are based on an individual data warehouse. End users spend a lot of time finding what they need. The support of one global catalog is a key component of a global information delivery system.

Metadata Management

Metadata is information about the data such as data source type, data types, content description and usage, transformations/derivations rules, security, and audit control attributes. Access to metadata is not limited to the data warehouse administrator but must also be made available to end users. For example, users want to know how revenue figures are calculated. Metadata defines rules to qualify data before storing it in the database. The end result is a data warehouse that contains complete and clean data.

Manageability

At present scenario data objects are distributed across the world and also reside on end-user workstations (laptops), it is a difficult to manage such environments. As part of its Customer Relationship Management (CRM) initiative, SAP is planning a Mobile Sales Automation (MSA) server that integrates and manages data between the SAP Business Information Warehouse and the data sets on a salesperson's laptop.

Adaptation of New Technologies

Implementation of an enterprise data warehouse is usually a multi-year project. echnically, as long as you have built your data warehouse based on an architecture using accepted industry standard APIs, you should be able to incorporate emerging technologies without extensive reengineering.

If your existing data warehouse environment uses open APIs, you can easily join information from multidimensional and relational data sources using ODBC. ODBO, for example, integrates multidimensional data from SAP BW and Microsoft's OLAP server. It shall be made sure that the data warehouse can adopt new emerging technologies with the least amount of work.

Security

A data warehouse environment must support a very robust security administration by using roles and profiles that are information object behavior-centric rather than pure database-centric. For example, a role such as cost center auditor defined in a data warehouse allows one to view cost center information for a specific business unit for a given quarter but not to print or download cost center information to the workstation.

Reliability and Availability

New data warehouse construction products provide methods to make systems highly available during data refresh. Products like SAP BW refresh a copy of an existing data object for incoming new data updates while end users keep using the existing information objects. However, when a new information object is completely refreshed, all new requests are automatically pointed to the newly populated information object. Such technologies must be an integral component of enterprise data warehouses.

Upgradability and Continual Improvements

If any component of a data warehouse (database management system, hardware, network, or software) needs upgrades, it must not lock out users, preventing them from doing their regular tasks. Moreover, any time a new functionality is added to the environment, it must not disrupt end-user activities. One can apply certain software patches or expand hardware components (storage) while users are using the data warehouse environment. During such upgrades, end users may notice some delays in retrieving information, but they are not locked out of the system.

Scalability and Data Distribution

Due to large data volume movement requirements, data warehouses consume enormous network resources (four- to five-fold more than a typical OLTP transaction environment). In an OLTP environment, one can predict network bandwidth requirements because data content associated with each transaction is somewhat fixed. In data warehousing, it is very hard to estimate network bandwidth to meet end-user needs because the data volume may change for each request based on data selection criterion. Large data sets are distributed to remote locations across the world to build local data marts. The network must be scalable to accommodate large data movement requests.

To build dependent data marts, you need to extract large data sets from a data warehouse and copy them to a remote server. A data warehouse must support very robust and scalable services to meet data distribution and/or replication demands. These services also provide encryption and compression methods to optimize usage of network resources in a secured fashion.

This can be demonstrated as shown below.

Data Ware house components

Data Provider Layer

The Data Provider layer is the primary gateway to the data sources (OLTP applications or other). Major tasks performed at this layer provide an environment in which to construct subject-oriented data analysis models.

Metadata (data about the data) is pulled in to a data warehouse environment from its data sources. Extraction, Transformation, and Transport services fetch data from data sources, qualify, perform value-added data manipulation, and push data out to data warehouse data objects. Key services performed at this layer are the following:

Data Transport
Data Transformation
Data Cleansing
Data Extraction
Subject Models

Service Provider Layer

The Service Provider layer is responsible for managing and distributing data objects across the Enterprise to support business intelligence activities in a controlled and secured fashion. At this layer, data is further transformed for specific data analysis tasks such as drill-down analysis and predefined reports integration with third-party subscribed data.

Moreover, data/text-mining data services transform data into knowledge by applying analytical techniques or combining structured and unstructured data, such as building a Web-centric environment by authoring Web pages to merge product sales data, charts, graphs, and product images. This layer is very complex within the data warehouse architecture. Key services performed at this layer are the following:

Analytical Applications Integration
Data Distribution
Data Profiling
Data Partitioning
Information Authoring
Data Consolidatio
Data Staging
Data Storage

The Information Consumer layer

It accesses information objects from a data warehouse. Information delivery services, provided by service providers, must be robust enough to handle large data volumes and multimedia objects. Keep in mind that not all end users have the same needs. Some users simply want to look at a list of numbers.

Some may want to have push-button models to see charts and graphs, and analysts may need access to large volumes of data to do extensive data analysis. Data access and delivery services must be robust enough to handle all such scenarios. Key services performed at this layer are the following:

Information Presentation
Search Engines
End-User Data Synchronization
Data Conversions
Information Access APIs
Information Consumer Profiling
Global Catalogs
Information Delivery

Data Warehouse Management Layer

The Data Warehouse Management layer provides services to manage all data objects in all layers. Additional services at this layer include component installation, monitoring, tuning, scheduling, networking, database operations, and component problem tracking/analysis that can be performed globally. Key services performed at this layer are the following:

Governing Services
Track Resource Utilization
Audit and Controls
Scheduling
Client Profile
Multi-Tiered Models
Warehouse Operations
Source/Target Management
Data Dictionary
Development Management
Hardware/Software
Security
Metadata

It is demonstrated as shown below.

Previous Posts are about Procurement to payment process SAP XI Introduction EDI Process and Compliance software testing

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

Procurement to payables Process

Procurement/purchasing activities

The procurement process commences with determining the requirement for materials/services. A purchase requisition should be raised for all goods/services that the organisation procures. Requisitions may be raised with reference to a contract or outline agreement which specifies a certain volume of a material that should be purchased from a particular vendor.

The system can also suggest an appropriate vendor for the material/service being procured via source determination (a vendor may be selected from a source list). The ability to approve/release purchase requisitions should be controlled via release procedures in the SAP system to ensure that only employees with the appropriate authority can authorise a purchasing transaction. Where appropriate, the system should enforce a tender evaluation process via ‘request for quotation’ functionality.

Purchase orders can then be created based on the requisitions and any related quotations. Purchase orders should not be created without reference to a purchase requisition. Any changes to the purchase requisition or purchase order should be subject to the appropriate approval procedures. Appropriate reports should be used to monitor long outstanding purchase orders. Master data relevant to the procurement cycle includes the vendor master and material master files.
Goods receipt

A goods receipt or the entry and acceptance of services should be performed for each purchase order. The goods receipt should be processed with reference to the corresponding purchase order. The entry and acceptance of services should be separated to ensure the appropriate authorization of services accepted for payment.

Invoice processing

Invoices are processed with reference to the appropriate purchase order and goods receipt transactions via the invoice verification transaction. Invoices that do not have a valid purchase order can be processed separately via the financial accounting accounts payable module. Any invoices that do not match the purchase order and goods receipt details within defined tolerances are automatically blocked for payment.

Invoices that do not relate to a valid purchase order in the system (eg utility payments) should be processed via the financial accounting accounts payable module. These invoices are not subject to the electronic approval enforced at the requisition stage and can be subject to authorisation controls at the invoice stage via payment release procedures used in conjunction with the ‘park and post’ functionality and SAP Workflow, to ensure that all invoices beyond a certain amount are authorised in accordance with approved delegation levels.

Payment processing

Payment runs should be performed on a regular basis and all payment reports, including payment exceptions (ie. blocked invoices), should be reviewed to ensure all payments are reasonable. Payments and the claiming of prompt payment discounts are driven by the payment terms, which should be entered in the vendor master record and should not be changed in the purchase order or invoice. Manual cheques should not be used, as the payment program can be run as frequently as required to process payments. This ensures an adequate level of control over payments and reduces the risk of unauthorized payments.

Previous Post is about SAP XI Introduction

ABAP TOPIC WISE COMPLETE COURSE

SAP XI What is it ?

SAP XI is an integration technology and platform…

…for SAP and non-SAP applications.
…for A2A and B2B scenarios.
…for asynchronous and synchronous communication.
…for cross-component Business Process Management.

A goal of the Exchange Infrastructure (XI) is to provide a single point of integration for all systems, SAP and non-SAP, inside and outside the corporate boundary.

1.The XI supports B2B as well as A2A exchanges; supports synchronous and asynchronous message exchange; and includes a built-in engine for designing and executing Integration Processes (Business Processes).

2. An important feature of the XI is that it provides openness and transparency to the integration process.

SAP NetWeaver is the integration and application platform for mySAP solutions; XI represents the Process Integration layer of the NetWeaver stack, and is a crucial element of the Enterprise Services Architecture (ESA).

It Unifies and aligns people, information and business processes and

1. Integrates across technologies and organizational boundaries
2. A safe choice with full .NET and J2EE interoperability

The business foundation for SAP and partners

1. Powers business-ready solutions that reduce custom integration

2. Its Enterprise Services Architecture increases business process flexibility(10)

ABAP TOPIC WISE COMPLETE COURSE

SAP XI File Adapter

The file adapter is used to read and write files at the OS level. The OS-level directory must be accessible by the service user of the Adapter engine, with the appropriate read/write permissions.

The file adapter can also act as an FTP client, meaning that it can perform GET and PUT in the sender and receiver case, respectively.

File adapter Sender :

When a queue name is specified, it gets created in XI automatically.

File Processing Parameters:

Quality of Service

Best Effort
EO
EOIO Specify Queue name in this case

Poll Interval

Processing Mode

Archive w.timestamp possible
Set to Read only
Delete
Test

Processing Sequence

Operating system command(33)

Related Posts :

XI adapter flow deployment of variants
EDI converter for SAP and EDI standards

ABAP TOPIC WISE COMPLETE COURSE

SAP XI adapter Flow Deployment of Variants

Three possibilities for deploying the adapter framework (deployment variants):

Central adapter engine (included by default in the Integration Server installation)
Local adapter engine (0 or more based on customer requirements)
PCK (for B2B communication)

The advantage is that the three operate in a consistent way, which provides for easier configuration, maintenance and monitoring.

SAP XI Adaptar Message flow

This is the simplified flow for a typical message entering the AE from the IS. Communication between the IS and AE is done using the XI-protocol (SOAP w/ attachments) over HTTP(s).

Upon arrival in the J2EE engine the message is queued and persisted as appropriate. These services are provided by the messaging layer.

The message goes through a series of modules (generic and specific, possibly custom written).

The message is posted to the backend application using the appropriate native protocol The core services provided by the AF (described in the previous slide) are leveraged throughout the joutney of the message in the AE.

The PCK is using the same adapter framework providing core services.

Since the PCK is intended to be completely detached from the Integration Server (different business partner), central configuration and adminsitration is not possible.

Therefore the following components have been provided with the PCK Configuration UI (which is really a lean Integration Directory) Monitoring and administration UI.

SAP XI Aarchitecture of the Adapter Frame work

The Adapter framework is the underlying technology supporting most of the XI adapters. The slide shows the internal architecture of the AF.

As a quick walkthrough of the slide, here is an explanation of the numbers present in the diagram:

1: Each specific adapter (developed either by SAP or a third-party) must comply with the JCA 1.0 specification (Java Connector Architecture). For instance, the adapter logic must have a system contract and application contract with the base J2EE engine.

2/3: Internally, each specific adapter is considered as a “module“ attached to the adapter framework module processor.

The module contains the logic specific to a given adapter. New modules can also be developed by the customer when there is a need for custom Java Code at the adapter level. The module is then called like a ‚user exit‘ and must be referenced explicitely in the communication channel configuration. Standard modules from SAP do not need to be referenced explicitely (with the exception of the SOAP adapter).

4: The adapter-specific configuration objects are accessed locally from the CPA Cache, which itself is derived from Integration Directory (central configuration). See the chapter on CPA-cache for more details.

5: The AF provides some administration services common for all adapters (ie monitoring and health check). Most of the administration features are accessible from the runtime workbench. However some AF administration is done in the J2EE Administrator tool directly . The adapter framework has its own persistence layer, which is in the database schema underlying the J2EE engine.

6: low-level technical utilities (threads, transaction management). Standard features of the J2EE engine are leveraged here.

7: logging API: the logging is consistent with the rest of the applications deployed in the J2EE Engine.

8: The message metadata is derived directly from the Integration Repository.

9: The Integration Repository also contains ‚adapter metadata‘. This is how the containers for the adapter-specific configuration are defined. This is also how 3rd parties can define such containers for additional adapters. The adapter metadata translates into adapter-specific configuration screens in the ID. It is consumed by the adapter framework at runtime.

The Adapter Framework resides on the SAP J2EE Engine 6.40. In the case of the JMS and JDBC adapters, the appropriate vendor-specific drivers must be deployed on the J2EE Engine in order to function properly.

SAP XI Connectivity

PCK is based on the adapter framework.

PCK does not inherit central configuration data from the Integration Directory PCK has its own user interface (which is a subset of the Integration Directory) for configuration of individual adapters.

SAP Partner Connectivity Kit (PCK) is based on Adapter Framework .

SAP PCK‘s objective is to enable XML document exchange between SAP XI and business partner not using SAP XI .

SAP PCK also provides an extensible platform for developing and running individual JCA Resource adapters.

Communication between SAP XI and SAP PCK is via SAP XI messaging protocol SAP PCK Includes the following adapters: File/FTP, JDBC, JMS, SOAP, RFC, IDoc (once available for SAP PCK).

Optionally SAP PCK can host further adapters that are available from SAP or 3rd party adapter providers.

Enablement of smaller companies / subsidiaries to exchange XML documents with their business partner’s / headquarter’s SAP XI as shown below.

platform for development of own JCA Resource Adapters is shown below.

Sample code to send mail from SAP

A sample program to send mail from SAP to Outlook with a text on body not at attachment.

report zh_email1.
data: email type somlreci1-receiver value ''.
data: sender type soextreci1-receiver value 'SAPDEV02'.

data: imessage type standard table of solisti1 with header line,
iattach type standard table of solisti1 with header line,
ipacking_list like sopcklsti1 occurs 0 with header line,
ireceivers like somlreci1 occurs 0 with header line.

start-of-selection.

clear imessage. refresh imessage.
imessage = 'This is a mail from SAP ECC6'.
append imessage.
imessage = 'Thanks and Regards'.
append imessage.
imessage = 'xyzabax'.
append imessage.

perform send_email tables imessage
using email
'Mail from xyzbax'.

**************************************************************
*

* Form SEND_EMAIL

**************************************************************
*
form send_email tables pit_message
using email
p_mtitle.

data: xdocdata like sodocchgi1,
xcnt type i.

* Fill the document data.

xdocdata-doc_size = 1.

* Populate the subject/generic message attributes

xdocdata-obj_langu = sy-langu .
xdocdata-obj_name = 'SAPRPT' .
xdocdata-obj_descr = p_mtitle .


clear ipacking_list. refresh ipacking_list.
ipacking_list-transf_bin = space.
ipacking_list-head_start = 1.
ipacking_list-head_num = 0.
ipacking_list-body_start = 1.
describe table imessage lines ipacking_list-body_num.
ipacking_list-doc_type = 'RAW'.
append ipacking_list.


clear ireceivers.
refresh ireceivers.
ireceivers-receiver = email.
ireceivers-rec_type = 'U'.

append ireceivers.
call function 'SO_DOCUMENT_SEND_API1'
exporting
document_data = xdocdata
put_in_outbox = 'X'
sender_address = sender
commit_work = 'X'
tables
packing_list = ipacking_list
contents_txt = imessage
receivers = ireceivers
exceptions
too_many_receivers = 1
document_not_sent = 2
document_type_not_exist = 3
operation_no_authorization = 4
parameter_error = 5
x_error = 6
enqueue_error = 7
others = 8.


*** These two statemnets are used to force the
mail to send it to the
*receipeint otherwise we need to go to SOST
tcode where we need to press
* F8 to send the mail to the other user.
To avoid this we need to use
*these two statemnets. Here the mail is not in queue.

submit rsconn01 using selection-set 'INT' and return.
call function 'SO_DEQUEUE_UPDATE_LOCKS'.
* SUBMIT rsconn01 WITH mode   = 'INT'
*                      WITH output = 'X'
*                      AND RETURN.

endform.

UPLOAD XML FILE FROM APPLICATION SERVER

Here is the code for uploading XML file from application server into data base server of SAP.

TYPE-POOLS: ixml. "iXML Library Types
*TABLES : rbkp.

&---------------------------------------------------------------------

* TYPE DECLERATIION

&---------------------------------------------------------------------

TYPES: BEGIN OF type_tabpo,
ebeln TYPE ekko-ebeln, "PO document number
ebelp TYPE ekpo-ebelp, "PO line item
END OF type_tabpo.

TYPES: BEGIN OF type_ekbe,
belnr TYPE rbkp-belnr, "Invoice document
gjahr TYPE rbkp-gjahr, "fiscal year
END OF type_ekbe.

TYPES: BEGIN OF type_invoice,
belnr TYPE rbkp-belnr, "PO document number
gjahr TYPE rbkp-gjahr, "Fiscal Year
rbstat TYPE rbkp-rbstat, "invoice status
END OF type_invoice.

TYPES: BEGIN OF t_xml_line, "Structure for holding XML data
data(256) TYPE x,
END OF t_xml_line.

&---------------------------------------------------------------------

* INTERNAL TABLE DECLERATIION

&---------------------------------------------------------------------

DATA: gi_tabpo TYPE STANDARD TABLE OF type_tabpo,
gi_ekbe TYPE STANDARD TABLE OF type_ekbe,
gi_invoice TYPE STANDARD TABLE OF type_invoice,
gi_bapiret2 TYPE STANDARD TABLE OF bapiret2.

DATA: l_ixml TYPE REF TO if_ixml,
l_streamfactory TYPE REF TO if_ixml_stream_factory.

* l_parser TYPE REF TO if_ixml_parser,
* l_istream TYPE REF TO swif_ixml_istream,
* l_document TYPE REF TO if_ixml_document,
* l_node TYPE REF TO if_ixml_node,
* l_xmldata TYPE string.

*DATA: l_elem TYPE REF TO if_ixml_element,

* l_root_node TYPE REF TO if_ixml_node,
* l_next_node TYPE REF TO if_ixml_node,
* l_name TYPE string,
* l_iterator TYPE REF TO if_ixml_node_iterator.

DATA: l_xml_table TYPE TABLE OF t_xml_line, " XML Table of the structure

l_xml_line TYPE t_xml_line, " Record of structure t_xml_line
l_xml_table_size TYPE i. " XML table size

DATA: l_filename TYPE string.

----------------------------------------------------------------

* WORK AREA DECLARATION

----------------------------------------------------------------

DATA: gw_tabpo TYPE type_tabpo,
gw_ekbe TYPE type_ekbe,
gw_invoice TYPE type_invoice,
gw_bapiret2 TYPE bapiret2.

*********************************************************************

* BEGIN OF SELECTION SCREEN

*********************************************************************

SELECTION-SCREEN BEGIN OF BLOCK blk1 WITH FRAME TITLE text-001.

PARAMETERS: p_file TYPE pathintern LOWER CASE DEFAULT '/usr/sap/tmp/'.

* Validation of XML file: Only DTD included in XML document is supported

SELECTION-SCREEN END OF BLOCK blk1.

***********************************************************************

* INTIALISATION.

***********************************************************************

INITIALIZATION.

***********************************************************************

* SELECTION SCREEN VALIDATION

***********************************************************************

AT SELECTION-SCREEN.

* To validate p_file is not initial

PERFORM sub_validate_file.

* PERFORM sub_validate_path.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_file.

* Request for filename for xml file from the application server

PERFORM sub_get_filename_appl USING p_file.

***********************************************************************

* START OF SELECTION SCREEN

***********************************************************************

START-OF-SELECTION.

PERFORM sub_fetch_po_details.

PERFORM sub_get_invoice.

PERFORM sub_rel_invoice.

***********************************************************************

* END OF SELECTION SCREEN

***********************************************************************

END-OF-SELECTION.

&---------------------------------------------------------------------
*& Form sub_validate_file
&---------------------------------------------------------------------

* To Validate the file

*
----------------------------------------------------------------------
FORM sub_validate_file .

IF p_file IS INITIAL.
MESSAGE e000. "specify the file path

ENDIF.

ENDFORM. " sub_validate_file

&---------------------------------------------------------------------
*& Form sub_get_filename_appl
&----------------------------------------------------------------------
form sub_get_filename_appl USING l_fname TYPE any.

* DATA: l_fname TYPE filename-fileintern. " File name

*GET THE FILENAME FROM THE APPLICATION SERVER

CALL FUNCTION '/SAPDMC/LSM_F4_SERVER_FILE'
EXPORTING
directory = l_fname
filemask = '*'
IMPORTING
serverfile = l_fname
EXCEPTIONS
canceled_by_user = 1
OTHERS = 2.
IF sy-subrc 0.

* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.
ENDFORM. " sub_get_filename_appl

&---------------------------------------------------------------------
*& Form sub_fetch_po_details
&---------------------------------------------------------------------

* To fetch the PO details from the application server
* Format of file is XML

*----------------------------------------------------------------------

FORM sub_fetch_po_details .

************************************************************************

* TYPE DECLERATIION

************************************************************************

l_ixml = cl_ixml=>create( ).

* Creating a stream factory

l_streamfactory = l_ixml->create_stream_factory( ).

PERFORM get_xml_table.

LOOP AT gi_tabpo INTO gw_tabpo.
WRITE:/ gw_tabpo.
ENDLOOP.

ENDFORM. " sub_fetch_po_details

&--------------------------------------------------------------------
*& Form get_xml_table
&--------------------------------------------------------------------

* Read from the xml file

---------------------------------------------------------------------
FORM get_xml_table .

************************************************************************

* Local variable declarations

************************************************************************

DATA: l_len TYPE i,
l_len2 TYPE i,
l_tab TYPE tsfixml,
l_content TYPE string,
l_str1 TYPE string,
c_conv TYPE REF TO cl_abap_conv_in_ce,
l_itab TYPE TABLE OF string.

l_filename = p_file.

***********************************************************************

* code to upload data from application server

***********************************************************************

OPEN DATASET l_filename FOR INPUT IN BINARY MODE.
IF sy-subrc 0.
WRITE:/ 'invalid file path'.
ENDIF.
DO.
READ DATASET l_filename INTO l_xml_line.

IF sy-subrc EQ 0.

APPEND l_xml_line TO l_xml_table.

ELSE.
EXIT.
ENDIF.
ENDDO.

CLOSE DATASET l_filename.

* code to find the table size

DESCRIBE TABLE l_xml_table.
l_xml_table_size = ( sy-tleng ) * ( sy-tfill ).

*code to convert hexadecimal to XML

LOOP AT l_xml_table INTO l_xml_line.

c_conv = cl_abap_conv_in_ce=>create( input = l_xml_line-data
replacement
= space ).
c_conv->read( IMPORTING data = l_content len = l_len ).
CONCATENATE l_str1 l_content INTO l_str1.

ENDLOOP.

l_str1 = l_str1+0(l_xml_table_size).
SPLIT l_str1 AT cl_abap_char_utilities=>cr_lf INTO TABLE l_itab.
LOOP AT l_itab INTO l_str1.
REPLACE ALL OCCURRENCES OF cl_abap_char_utilities=>horizontal_tab IN
l_str1 WITH space.
ENDLOOP.

CALL TRANSFORMATION ('ID') " code to put in internal table
SOURCE XML l_str1
RESULT tab = gi_tabpo[].

ENDFORM. " get_xml_table

The previous post of the blog is regarding COLORING CELLS USING ALV REPORT

SAP AND ABAP TOPICS

Global Information Delivery

Global Catalog

Metadata Management

Manageability

Adaptation of New Technologies

Security

Reliability and Availability

Upgradability and Continual Improvements

Scalability and Data Distribution

The Data Provider layer is the primary gateway to the data sources (OLTP applications or other). Major tasks performed at this layer provide an environment in which to construct subject-oriented data analysis models.