Introduction
I have written several times on the topic of WebServices from the ABAP content:

• ABAP WebServices: Logon Language Processing
• WebService Navigator Page for ABAP and Java
• WebServices: A real world implementation experience
• Publishing ABAP WebServices to an External UDDI Server
• Develop a Web Service that sends an Email - in ABAP
• BSP a Developer's Journal Part XIV - Consuming WebServices with ABAP
• BSP – a Developer’s Journal Part XIII: Developing ABAP WebServices

You would think that I would run out of things to write about on WebServices. But it seems like every time we do a new project using the technology, I learn something new. Maybe that is why I enjoy working with WebServices so much. Well this week was no different. A college of mine, Chris Cassidy, had a project where he needed to call a WebService from ABAP. So far so good. However the WebService he was going to be calling (written in .Net) required HTTPS and Basic Authentication. This was something we had never done before (and I had never written about). We were able to work though the setup with a few minor problems along the way. Thanks to Chris's excellent note taking, I can now share those details and learning's here today.

.Net Side - Setup
I don't want to focus too much on the development from the .Net Side. I will give you a little background however. We were developing a .Net WebService that would call MSSQL stored procedures in our shop floor MES system. This call would actually be triggered out of our 46C R/3 system from an User Exit in the QM Inspection Lot Maintenance Application. This way when Usage Decisions are made in R/3 we will update the Shop Floor system (by passing through R/3 to our 640 Standalone WebAS system) in real time. Given that this was very important Quality data, we wanted to make sure that the data was secure. We also needed the user who authenticated to the WebService to have its credentials passed through to the SQL Server database. This caused us to have to require SSL (HTTPS) for the WebService communication. We have an internal Certificate Server at our company. We needed to setup the Root Certificate for this internal CA on the Web Server that was going to host the WebService. We also needed to go into IIS for this WebService and force it to require Secure Communications. The following are some screen shots of the configuration we did in IIS:

IIS Configuration - Authentication

IIS Configuration - HTTPS

SAP Side - Setup
I didn't go into much detail on the WebService setup on the .Net or IIS side. We found plenty of detailed documents on that other Developers' Network on the subject. We are all here because we are interested in how to do the ABAP side of the setup - right? First of all you can following most of the setups detailed in the following weblog: BSP a Developer's Journal Part XIV - Consuming WebServices with ABAP. The webservice proxy generation itself isn't really any different. When we begin to get differences is in the setup of the Logical Port (Transaction LPCONFIG). All my examples in the past have used the URL option in the Call Parameters for the Logical Port. This is fine as long as the connection requires no additional parameters for authentication or security. To go beyond plain HTTP URL connections, you have to use an RFC Connection of Type G (HTTP Connection to Ext. Server). Before we jump to SM59 to setup our RFC, I want to show you the area of the Logical Port I am referring to:

Logical Port Setup

I have setup HTTP based RFC connections before. It isn't too difficult. You supply your Target Host, Path and Port number (called Service No. in the User Interface) on the Technical Settings Tab. We are going to be using HTTPS to connect to the IIS WebService, so don't forget that your Port will not be the default (80). HTTPS defaults to 443.

RFC Setup - Technical Settings

The next tab (Logon/Security) is where we can setup our requirement for SSL (HTTPS) and that we are wanting to use Basic Authentication. This is also where we choose the user name and password to use for the Basic Authentication. Notice that when you choose Basic Authentication combined with SSL the SSL Client Certificate Detail Drop Down forces in the value for SSL Client (Anonymous). You can not override this value. Remember this Client Certificate because it becomes very important later on.

RFC Setup - Logon/Security

The final tab (Special Options) allows you set Compression, Timeout and Cookie options. Now I suggest the following settings for HTTP Settings (compression). We turned on compression initially. However we were unable to call the WebService through the ABAP proxy using Compression. We received an error that the first character of the HTML stream contained an unknown Hex Value. Turning off compression quickly corrected this error. I'm not sure if you should be able to use compression or not. Perhaps this is just a bug either in .Net or in our WebAS 640 SP10 system.
RFC Setup - Special Options

We thought it would be a good idea to test our RFC HTTP connection from SM59 before we even try to test our WebService itself. Unfortunately we immediately received an error message. The details from the ICM log were as follows:

Now I had to clip the right edge of the screen to get an image that conformed to the SDN limits. Don't worry though, you aren't missing much. A few hours of reading documents on SDN, the Service Marketplace, and through the Internet (gotta love Google) lead us to better understand the nature of SSL Client calls out of the ABAP WebAS. This is the way I understand it: In order to establish a Secure HTTP communication with a foreign system, SAP must verify the other party's server certificate. To do this SAP must have access to the Certificate for the Trusted Root Authority that signed the foreign Server certificate. This Certificate must then be associated to the profile used during Anonymous SSL (even though no actual client certificate from the WebAS is required). Remember that certificate setting from the RFC setup that I told you not to forget? This is where it comes into play.

We will start off by getting our Trusted Root Certificate. Remember that I said early we have our own certificate server (which is fairly common these days as I understand). Therefore I know that my browser (IE) has this certificate in it as well. From Tools->Internet Options->Content Tab->Certificates->Trusted Root Certification Authorities Tab, I can access and download the certificate that I need.

Now I need to load this certificate that I just downloaded into SAP and associate it to the SSL Client (Anonymous) profile. You can do this work from transaction STRUST.

Now I would like to tell you that after uploading the certificate, the RFC destination connected just fine and we left work early that day to head over to the local watering hole. Unfortunately that was not the case. The connection continued to fail with the same error message. In fact we spent another 4 hours playing with settings, reading, and retrying without any luck. Well past sundown I finally stumbled across an OSS note I wish I had found hours ago. It was OSS Note 510007. It had detailed instructions on how to setup SSL on the SAP WebAS. However it was the very last line of this Note that was so important:

Bear in mind that the changes made in the trust manager will only take effect after you restart the application server or at least the ICM (transaction SMICM, Administration -> ICMAN -> Exit Soft).

Sure enough, we restarted the ICM and everything started working just fine. I would have never guessed that I needed to restart the ICM just to add a certificate!

Closing
Hopefully I have been able to share another small piece of the very large WebServices puzzle. And maybe if you read this weblog, you might be able to avoid the very frustrating afternoon that we experienced trying to setup the SSL connection.

Thomas Jung Thomas Jung is an SAP Technology Solution Architect focusing on Custom Development Tools - particularly in the areas of ABAP and User Interface Technology.

출처: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/1645

Tcode: SHD0
enter Tcode: VA01( for eg)
enter transaction variant : ZDISP ( If you want to put some fileds in gray mode),
press create button,
u ll get the regula sales order creation screen, enter the respective details and go on, according to the system proceedings,and maitain the field properties where ever ;you required.
when u reach to the final screen,it will ask u to save the document?
click on "Yes", now sales order will generate, (here transaction variant is created vth ZDISP)
now goto VOV8, select your doc type- details
in transaction flow- variant filed, assign newly created variant name ie. ZDISP

from now, whenever you use that doc type, according to the settings stored in that variant,sales order will works.

Business Case:
As a part of reorganization and to better serve the customer needs, you are regrouping many of the customers. In SAP terms, you are changing the Sales Office, Sales Group and Customer Groups for specific Customer Master Records. Typically, you would maintain customer records with transaction XD02 to update 'Sales View'. You would enter Customer Key (Customer No, Sales Organization, Distribution Channel, and Division) and update relevant fields on Sales View screen. 
This document contains Step-by-step instructions to use LSMW to update Customer Master Records. It has two demonstration examples - one using Batch Recording and another using standard SAP Object.  

Demo Example 1

LSMW to Update Customer Master Records with Transaction Recording

  
Call Legacy System Migration Workbench by entering transaction code LSMW. Every conversion task is grouped together as Project / Subproject / Object structure. Create a Project called LSMW_DEMO and a Subproject as CUSTOMERS and Object as CUST_REC as shown in Figure Below.     

      
The main screen of LSMW provides wizard-like step-by-step tasks, as shown in Figure below. To complete your data conversion, you need to execute these steps in sequence. Once a step is executed, the cursor is automatically positioned to the next step. 

 Note that these steps may look different depending upon your Personal menu settings. You could make step numbers visible by 'Numbers on' icon or hidden by 'Numbers off' icon. You can execute a step by double-clicking on the row. Toggle icon 'Doubleclick=Display' or 'Doubleclick=Edit', makes the step in 'display' mode or 'change' mode.

 
      

Step 1: Maintain Object attributes

In this example, you will be updating the customer master records with the help of recording a transaction (XD02). Choose radio button Batch Input Recording and click on the recording overview icon to record the R/3 transaction. Enter the Recording name as XD02_REC, the description as Customer Master Updates Recording, and the transaction code as XD02.       

 The system calls the transaction code XD02 and prompts you to complete the Change
Customer transaction, as shown in Figure 4. Enter the key customer information (I entered customer number 1000, sales organization 1000, distribution channel 01, and division 00) and choose 'Sales' view within 'Sales area data'. Make changes to these three fields (I entered, sales office 1010, sales group 110, and customer group 01) and save the transaction.   

  
Once the transaction is completed, R/3 records the flow of screens and fields and saves the information, as shown in Figure below.      

Note that the fields are populated with default values. The values you entered when you recorded the transaction are set by default.  
Note that if you have more fields in the recording than needed, you can remove them by clicking 'Remove Screen field' icon .

Observe that the transaction-recording process stores field names in a technical format. By pressing the F1 key on individual screen fields and then pressing the F9 key, the system displays technical names. You then can replace the technical names with descriptive names. Double-click on the field RF02D-KUNNR and enter the name as KUNNR and the description as Customer Account Number and remove the default value. (See Figure below.)      

Similarly, double-click on all other fields with default values and make appropriate changes. Once you have made changes, the recording overview screen looks like what you see in Figure below.        

Save your changes. When you go back to the initial screen, you will see that the initial screen steps have changed. Since you want to import data via the BDC method, the Direct Input and *IDoc-*related steps are hidden, as they are not relevant.   

Step 2. Maintain Source Structures

Give a name and a description to the source structure (Figure below).    

Step 3. Maintain Source Fields

In this step, you need to list what fields are present in the source structure. The easiest way is to click on 'Table Maintenance' icon to enter Fieldname, Type and Length for each field  as shown in Figure below.    

  

Note that your input file will have four fields as key fields and you need to update three fields in the system.  

Step 4: Maintain Structure Relations

Execute a step to 'Maintain Structure Relations'. (See Figure below.) Since, there is only one Source and Target Structure, the relationship is defaulted automatically.      

Step 5: Maintain field mapping and conversion rules

Field RF02D-D0310 represents that you chose 'Sales view' for the customer Master screen accordingly its value should be set to X. Keep your cursor on field RF02D-D0310 and click on Constant rule icon to choose the constant value of 'X'. 
If your source file already has the field value, you choose rule 'Source Field'.  
Keep cursor on field 'KUNNR' and click on 'Assign Source field' icon to choose source field CUSTOMER from structure XD02S as shown in Figure below.       

Similarly, assign 'Source Field' rules to the remaining fields.  
Once all the fields are mapped, you should have an overview screen as shown in Figure below.      

Step 6: Maintain fixed values, translations, user-defined routines

You can also maintain re-usable translations and user-defined routines, which can be used across conversion tasks. In this case, that step is not required.  

Step 7: Specify files

In this step, we define how the layout of the input file is. The input file is a [Community:Tab] delimited with the first row as field names. It is present on my PC (local drive) as C:\XD02.txt. (See Figure below.)      

Create an Excel file (Figure below) with your data and save it as a Tab-delimited text file on your local drive (C:\ and name it XD02.txt).     

Step 8: Assign files

Execute step 'Assign Files' (Figure below) and the system automatically defaults the filename to the source structure.      

Step 9: Read data

In this step, LSMW reads the data (Figure below) from the source file (from your PC's local drive). You have the option to read only selected rows and convert data values to Internal format.      

 

Step 10: Display read data

This step (Figure below) is optional. If required, you can review the field contents for the rows of data read.    

    

Step 11: Convert data

This is the step that actually converts the source data (in source format) to a target format. Based on the conversion rules defined, source fields are mapped to target fields.  

Step 12: Display Converted data

Again this is an optional step to view how the source data is converted to internal SAP format (Figure below).        

 

Step 13: Create batch input session

Once the source data is converted in an internal format, you can create a batch session to process updates (Figure below).       

  

Step 14: Run Batch Input Session

You can execute the BDC session by Run Batch input session. Executing a batch input session is a standard SM35 transaction for managing BDC sessions. Once you have successfully executed the batch input session, the customer master records are updated in the system. You can confirm this by viewing the customer master records (XD03).   
Note! Browsing thru these 14 steps, you may get a feeling that this is a very lengthy and time-consuming activity. However, for the purposes of demonstration, I have made it detailed. Although it looks lengthy, actually it takes hardly few hours from start-to-finish! After playing around with few simple LSMW scripts, you will find it so easy to change and create more complex ones.

출처: http://wiki.sdn.sap.com/wiki/display/CRM/Learning+LSMW+Step+by+Step%21%21%21

*&----------------------------------------------------------------*
*& Report  YRTEST0007
*&
*&----------------------------------------------------------------*
*&
*&
*&----------------------------------------------------------------*

report  YRTEST0007.


*-----------------------------------------------------------------*
end-of-selection.
*-----------------------------------------------------------------*
  data: ip type char15.

  call method cl_gui_frontend_services=>get_ip_address
    receiving
      ip_address           = ip
    exceptions
      cntl_error           = 1
      error_no_gui         = 2
      not_supported_by_gui = 3
      others               = 4.

  write: ip.

Process    :Tcode [XXCreate/Change/Display]

________________________________________________________________

Material Master                  : MM01/02/03
BOM                                        : CS01/02/03
                                                                                                                                   

Material Master

WorkCenter                          : CR01/02/03
Routing                                  : CA01/02/03

--------------------------------------------------------------------------------------
Sales Order                           : MC87/88/89

PIR (Demand Mgt)             : MD61/62/63                    
MRP Run                       : MD01/02/03                                                           

Sales Planning
MRP Evaluation              : Stock Req. List : MD04
MRP List                          : MD05
Order Conversion            : From Stock Req. List : MD04 or 
                                                                  : CO40

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

Create Prod. Order            : CO01/02/03

Confirmation                      : For Order             : CO15
                                              : For Operation     : CO11N
                                              : Error Processing: COGI

Good's Issue                       : MB1A                      Production Execution

Good's Receipt                  : MB31

TECO                                    : CO02         

The SQL Trace, which is part of the Performance Trace (transaction ST05), is the most important tool to test the performance of the database. Unfortunately, information on how to use the SQL Trace and especially how to interpret its results is not part of the standard ABAP courses. This weblog tries to give you a quick introduction to the SQL Trace. It shows you how to execute a trace, which is very straightforward. And it tells how you can get a very condensed overview of the results--the SQL statements summary--a feature that many are not so familiar with. The usefulness of this list becomes obvious when the results are interpreted. A short discussion of the ‘database explain’ concludes this introduction to the SQL Trace. 

1. Using the SQL Trace

Using the SQL trace is very straightforward:

1. Call the SQL trace in a second mode
2. Make sure that your test program was executed at least once, or even better, a few times, to fill the buffers and caches. Only a repeated execution provides reproducible trace results. Initial costs are neglected in our examination
3. Start the trace
4. Execute your test program in the first mode
5. Switch off the trace. Note, that only one SQL trace can be active on an application server, so always switch your trace off immediately after your are finished.
6. Display the trace results
7. Interpretation of the results

Note, the trace can also be switched on for a different user.

=> In this section we showed how the SQL trace is executed. The execution is very straightforward and can be performed without any prior knowledge. The interpretation of the results, however, requires some experience. More on the interpretation will come in the next section.

2. Trace Results – The Extended Trace List

 

When the trace result is displayed the extended trace list comes up. This list shows all executed statements in the order of execution (as extended list it includes also the time stamp). One execution of a statement can result in several lines, one REOPEN and one or several FETCHES. Note that you also have PREPARE and OPEN lines, but you should not see them, because you only need to analyze traces of repeated executions. So, if you see a PREPARE line, then it is better to repeat the measurement, because an initial execution has also other effects, which make an analysis difficult.

If you want to take the quick and easy approach, the extended trace list is much too detailed. To get a good overview you want to see all executions of the same statement aggregated into one line. Such a list is available, and can be called by the menu ‘Trace List -> Summary by SQL Statements’.

=> The extended trace list is the default result of the SQL Trace. It shows a lot of and very detailed information. For an overview it is much more convenient to view an aggregated list of the trace results. This is the Summarized SQL Statements explained in the next section.

3. Trace Results - Summarized SQL Statements

This list contains all the information we need for most performance tuning tasks.

The keys of the list are ‘Obj Name’ (col. 12), i.e. table name, and ‘SQL Statement’ (col. 13). When using the summarized list, keep the following points in mind:

• Several coding positions can relate to the same statement:
• The statement shown can differ from its Open SQL formulation in ABAP.
• The displayed length of the field ‘Statement’ is restricted, but sometimes the displayed text is identical.
• In this case, the statements differ in part that is not displayed.

The important measured values are ‘Executions’ (col. 1), ‘Duration’ (col. 3) and ‘Records’ (col. 4). They tell you how often a statement was executed, how much time it needed in total and how many records were selected or changed. For these three columns also the totals are interesting; they are displayed in the last line. The other totals are actually averages, which make them not that interesting.

Three columns are direct problem indicators. These are ‘Identical’ (col. 2), ‘BfTp’ (col. 10), i.e. buffer type, and ‘MinTime/R.’ (col. 8), the minimal time record.

Additional, but less important information is given in the columns, ‘Time/exec’ (col. 5), ‘Rec/exec’ (col. 6), ‘AvgTime/R.’ (col. 7), ‘Length’ (col. 9) and ‘TabType’ (col. 11).

 

For each line four functions are possible:

• The magnifying glass shows the statement details; these are the actual values that were used in the execution. In the summary the values of the last execution are displayed as an example.
• The ‘DDIC information’ provides some useful information about the table and has links to further table details and technical settings.
• The ‘Explain’ shows how the statement was processed by the database, particularly which index was used. More information about ‘Explain’ can be found in the last section.
• The link to the source code shows where the statement comes from and how it looks in OPEN SQL. 

=> The Statement summary, which was introduced here, will turn out to be a powerful tool for the performance analysis. It contains all information we need in a very condensed form.  The next section explains what checks should be done.

 

4. Checks on the SQL Statements

For each line the following 5 columns should be checked, as tuning potential can be deduced from the information they contain. Select statements and changing database statements, i.e. inserts, deletes and updates, can behave differently, therefore also the conclusions are different.

For select statements please check the following:

• Entry in ‘BfTy’ = Why is the buffer not used?
  The tables which are buffered, i.e. with entries ‘ful’’ for fully buffered, ‘gen’ for buffered by generic region and ‘sgl’ for single record buffer, should not appear in the SQL Trace, because they should use the table buffer. Therefore, you must check why the buffer was not used. Reasons are that the statement bypasses the buffer or that the table was in the buffer during the execution of the program. For the tables that are not buffered, but could be buffered, i.e. with entries starting with ‘de’ for deactivated (‘deful’, ‘degen’, ‘desgl’ or ;deact’) or the entry ‘cust’ for customizing table, check whether the buffering could not be switched on. 
• Entry in ‘Identical’ = Superfluous identical executions
  The column shows the identical overhead as a percentage. Identical means that not only the statement, but also the values are identical. Overhead expresses that from 2 identical executions one is necessary, and the other is superfluous and could be saved.
• Entry in ‘MinTime/R’ larger than 10.000 = Slow processing of statement
  An index-supported read from the database should need around 1.000 micro-seconds or even less per record. A value of 10.000 micro-seconds or even more is a good indication that there is problem with the execution of that statement. Such statements should be analyzed in detail using the database explain, which is explained in the last section.
• Entry in ‘Records’ equal zero = No record found
  Although this problem is usually completely ignored, ‘no record found’ should be examined. First, check whether the table should actually contain the record and whether the customizing and set-up of the system is not correct. Sometimes ‘No record found’ is expected and used to determine program logic or to check whether keys are still available, etc. In these cases only a few calls should be necessary, and identical executions should absolutely not appear.
• High entries in ‘Executions’ or ‘Records’ = Really necessary?
  High numbers should be checked. Especially in the case of records, a high number here can mean that too many records are read.

For changing statements, errors are fortunately much rarer. However, if they occur then they are often more serious:

• Entry in ‘BfTy’ = Why is a buffered table changed?
  If a changing statement is executed on a buffered statement, then it is questionable whether this table is really suitable for buffering. In the case of buffered tables, i.e entries ‘ful’, ‘gen’ or ’sgl’’, it might be better to switch off the buffering. In the case of bufferable tables, the deactivation seems to be correct.
• Entry in ‘Identical’ = Identical changes must be avoided
  Identical executions of changing statements should definitely be avoided.
• Entry in ‘MinTime/R’ larger than 20.000 = Changes can take longer
  Same argument as above just the limit is higher for changing statements.
• Entry in ‘Records’ equal zero = A change with no effect
  Changes should also have an effect on the database, so this is usually a real error which should be checked. However, the ABAP modify statement is realized on the database as an update followed by an insert if the record was not found. In this case one statement out of the group should have an effect.
• High entries in ‘Executions’ and ‘Records’ = Really necessary?
  Same problems as discussed above, but in this case even more serious.

=> In this section we explained detailed checks on the statements of the SQL Statement Summary. The checks are slightly different for selecting and changing statements. They address questions such as why a statement does not use the table buffer, why statements are executed identically, whether the processing is slow, why a statement was executed but no record was selected or changed, and whether a statement is executed too often or selects too many records.

5. Understanding the Database Explain

The ‘database explain’ should show the SQL statement as it goes to the database, and the execution plan on the database. This view has a different layout for the different database platforms supported by SAP, and it can become quite complicated if the statement is complicated.

In this section we show as an example the ‘Explain’ for a rather simple index-supported table access, which is one of the most common table accesses:

1. The database starts with step 1, index unique scan DD02L~0, where the three fields of the where-condition are used to find a record on the index DD02L~0 (‘~0’ denotes always the primary key).
2. In step 2, table access by index rowed DD02L, the rowid is taken from the index to access the record in the table directly.

Some databases display the execution plan in a graphical layout, where a double-click on the table gives additional information, as shown on the right side. There the date of the last statistics update and the number of records in the table are displayed. Also all indexes are listed with their fields and the number of distinct values for each field, with this information it is possible to calculate the selectivity of an index.

From this example you should understand the principle of the ‘Explain’, so that you can also understand more complicated execution plans. Some database platforms do not use graphical layouts and are a bit harder to read, but still show all the relevant information. 

=> In this last section we showed an example of a database explain, which is the only way to find out whether a statement uses an index, and if so, which index. Especially in the case of a join, it is the proper index support that determines whether a statement needs fractions of seconds or even minutes to be finished.

  

Please try the SQL Trace by yourself. If there are any questions or problems, your feedback is always welcome!

 

More information on performance topics can be found in my new textbook on performance (published Nov 2009). However please note, that it is right now only available in German.

Chapter Overview:

1. Introduction
2. Performance Tools
3. Database Know-How
4. Optimal Database Programming
5. Buffers
6. ABAP - Internal Tables
7. Analysis and Optimization
8. Programs and Processes
9. Further Topics
10. Appendix

In the book you will find detailed descriptions of all relevant performance tools. An introduction to database processing, indexes, optimizers etc. is also given. Many database statements are discussed and different alternatives are compared. The resulting recommendations are supported by ABAP test programs which you can download from the publishers webpage (see below). The importance of the buffers in the SAP system are discussed in chaptr five. Of all ABAP statements mainly the usage of internal tables is important for a good performance. With all the presented knowledge you will able to analyse your programs and optimize them. The performance implications of further topics, such as modularisation, workprocesses, remote function calls (RFCs), locks & enqueues, update tasks and prallelization are explained in the eight chapter.

Even more information - including the test programs - can be found on the webpage of the publisher.

I would recommend you especially the examples for the different database statements. The file with the test program (K4a) and necessary overview with the input numbers (K4b) can even be used, if you do not speak German!

Siegfried Boes is a member of the SAP Performance, Data Management & Scalability team

 *&----------------------------------------------------------------*
*& Report  YRTEST0005
*&
*&----------------------------------------------------------------*
*&
*&  Run Program with Background job
*&----------------------------------------------------------------*

report  yrtest0005.

* Run Program with Background job
  data: l_number type tbtcjob-jobcount,
        l_name   type tbtcjob-jobname.

  concatenate 'Z00' '_'  sy-datum '_'  sy-uzeit
         into l_name.

  call function 'JOB_OPEN'
    exporting
      jobname          = l_name
    importing
      jobcount         = l_number
    exceptions
      cant_create_job  = 1
      invalid_job_data = 2
      jobname_missing  = 3
      others           = 4.

  check sy-subrc = 0.
*  submit zlmmm65010 with  pa_bukrs =  pi_bukrs
*                    with  pa_gbm   =  l_gbm
*                    with  pa_week  =  pi_planid
*                    with  pa_ck01  =  c_x
*                    user  sy-uname
*                    via job l_name number l_number
*                    and return.

  submit yrtest0006 user  sy-uname
                    via job l_name number l_number
                    and return.

  check sy-subrc eq 0.
  message s303(me) with 'Success'.

  call function 'JOB_CLOSE'
    exporting
      jobcount             = l_number
      jobname              = l_name
      strtimmed            = 'X'
    exceptions
      cant_start_immediate = 1
      invalid_startdate    = 2
      jobname_missing      = 3
      job_close_failed     = 4
      job_nosteps          = 5
      job_notex            = 6
      lock_failed          = 7
      others               = 8. 




*&----------------------------------------------------------------*
*& Report  YRTEST0006
*&
*&----------------------------------------------------------------*
*&
*&
*&----------------------------------------------------------------*

report  yrtest0006.

*  include yrtest0006top.
*  include yrtest0006f01.


end-of-selection.
  write: sy-uname, sy-datum, sy-uzeit.

FM to get Production Order user status (CO03) and system status

  *&----------------------------------------------------------------*
*& Report  YRTEST0003
*&
*&----------------------------------------------------------------*
*&
*&
*&----------------------------------------------------------------*

REPORT  YRTEST0003.

  data: lt_STATUS like TABLE OF JSTAT with header line,
        l_OBJNR   LIKE JSTO-OBJNR,
        l_aufnr   like afko-aufnr.


  clear: l_OBJNR, l_aufnr.

  l_aufnr = '60003649'.

  call function 'CONVERSION_EXIT_ALPHA_INPUT'
    exporting
      input         = l_aufnr
    IMPORTING
      OUTPUT        = l_aufnr.

  concatenate 'OR' l_AUFNR into l_OBJNR.

  call function 'STATUS_READ'
    exporting
      CLIENT                 = SY-MANDT
      objnr                  = l_OBJNR
      ONLY_ACTIVE            = 'X'
*   IMPORTING
*     OBTYP                  =
*     STSMA                  =
*     STONR                  =
   TABLES
     STATUS                 = lt_STATUS
   EXCEPTIONS
     OBJECT_NOT_FOUND       = 1
     OTHERS                 = 2.

  data: l_txt04 like tj02t-txt04,
        l_TXT30 like tj02t-TXT30.

  clear: l_txt04, l_TXT30.

  if sy-subrc eq 0.
    loop at lt_status.
      write: / lt_status-STAT.
      clear: l_txt04, l_TXT30.
      select single txt04 TXT30
        into (l_txt04, l_TXT30)
        from tj02t
       where ISTAT eq lt_status-STAT
         and SPRAS eq SY-LANGU.
      write: l_txt04, l_TXT30.
    endloop.
  else.
    message s303(me) with sy-subrc.
  endif.

*  if not IT_JEST[] is initial.
*    select ISTAT TXT04
*    from TJ02T
*    into table IT_TJ02T
*    for all entries in IT_JEST
*    where ISTAT = IT_JEST-STAT
*      and SPRAS = SY-LANGU.
*  endif.

*&----------------------------------------------------------------*
*& Report  YRTEST0002
*&
*&----------------------------------------------------------------*
*&
*&
*&----------------------------------------------------------------*

report  yrtest0002.

  data: ls_return      like bapiret1,
        lt_return      like table of bapi_coru_return with header line,
        lt_timetickets like table of bapi_pp_timeticket with header line.

end-of-selection.
  clear: ls_return, lt_return[], lt_timetickets[].
  clear: lt_timetickets.

*  lt_timetickets-conf_no   = '0000104074'.
  lt_timetickets-orderid   = '60003649'.
  lt_timetickets-operation = '0010'.
  lt_timetickets-yield     = 1.

  data: l_aufnr type aufnr.

  call function 'CONVERSION_EXIT_ALPHA_INPUT'
    exporting
      input         = lt_timetickets-orderid
    IMPORTING
      OUTPUT        = l_aufnr.

  select single rueck
    into lt_timetickets-conf_no
    from afru
   where aufnr eq l_aufnr
     and vornr eq lt_timetickets-operation.

  append lt_timetickets.

  call function 'BAPI_PRODORDCONF_CREATE_TT'
    importing
      return                   = ls_return
    tables
      timetickets              = lt_timetickets
      detail_return            = lt_return.

  read table lt_return with key type = 'E'.
  if sy-subrc eq 0.
    call function 'BAPI_TRANSACTION_ROLLBACK'.
    message s303(me) display like 'E'
                     with lt_return-message.
  else.
    read table lt_return index 1.
    call function 'BAPI_TRANSACTION_COMMIT'.
    message s303(me) with lt_return-message.
  endif.