ISR Cookbook 2004 en

Internal Service Request (ISR)
Cookbook
How to Create Service Request Scenarios
July 2004
Stephan Rehmann, Martin Kreyscher, Dirk Ahlert
Web Form
Approve Request
Workflow
Processing
One or more
processors carry out
actions (for
example, creating
Cost of request is automatic
automatically correspondence or
determined (Easy Cost R/3 transactions)
Planning) and the
processor can trigger
automatic purchase
order generation (Easy
Execution)
Copyright © 2000 SAP AG, All rights reserved Page 1 of 83

Contents
1. Introduction.....................................................................................................................6
1.1 Main ISR Terms..........................................................................................................6
1.2 Prerequisites................................................................................................................6
2. Getting Started – A Simple Example..............................................................................7
2.1 Example Scenario: Applying for a New System User................................................7
2.2 General Scenario Data................................................................................................7
2.3 Defining Characteristics for the Form........................................................................8
2.4 Defining Tasks for the Notification............................................................................9
2.5 Generating the Form (ITS Version)............................................................................9
2.6 Generating the Adobe Form.....................................................................................10
2.7 Costs..........................................................................................................................11
2.8 Running the Scenario................................................................................................12
2.8.1 Applicant with ITS Scenario.............................................................................12
2.8.2 Applicant with Scenario in Enterprise Portal (Adobe Form)............................12
2.8.3 Administrator....................................................................................................13
2.9 Checklist for New ISR Scenarios.............................................................................14

3. Basic Customizing........................................................................................................15
3.1 General Details.........................................................................................................15
3.2 Request Entry Type..................................................................................................16
3.2.1 Entry Using ITS Service...................................................................................17
3.2.2 Entry Using Adobe PDF...................................................................................18
3.3 Entry Using JSP iView.............................................................................................18

3.4 Entry Using BSP.......................................................................................................19
3.5 Flow Logic with BAdI Implementations..................................................................19
3.6 Characteristics...........................................................................................................19
3.7 The Action Box.........................................................................................................21
3.7.1 Overview...........................................................................................................21
3.7.2 Defining the Action Box...................................................................................22
3.8 Tasks.........................................................................................................................22
4. The Request Form as an Internet Service (ITS Technology).......................................24
4.1 Setting Up an Internet Service for the ISR...............................................................24

4.2 Layout Options for the Request Form......................................................................25
4.2.1 SAP Design or Plain HTML.............................................................................25
4.2.2 Different Layouts Enabled by Additional Themes...........................................25
4.2.3 Different Layouts for Different Request Modes (Create/Change/Display)......26
4.2.4 Layout Based On User Role.............................................................................26
4.2.5 Page Layout and Scrolling Logic......................................................................26
4.2.6 Layout Based On Values of Individual Fields..................................................27
4.3 Elements of the Request Form..................................................................................27

4.3.1 SAP Design with Business HTML...................................................................27
4.3.2 Plain HTML......................................................................................................29
4.4 Initialization, Input Help, Verification, and User Commands..................................32

4.4.1 Initialization Through Parameterized URL Call...............................................32
4.4.2 Initialization, Input Help, and Verification for Clients in HTML Template....32
4.4.3 Programming BAdIs.........................................................................................32
5. Request Form as Java iView in Enterprise Portal 5.0...................................................38

5.1 Generating and Installing a Java iView for the ISR.................................................38
5.2 Layout Options.........................................................................................................41
5.2.1 Images...............................................................................................................43
5.2.2 Access to Form Data.........................................................................................43
5.2.3 Layout and HTMLB.........................................................................................43
5.2.4 Different Layouts for Different Request Modes (Create/Change/Display)......43
5.2.5 Layout Based On User Role.............................................................................44
5.2.6 Page Layout and Scrolling Logic......................................................................44
5.2.7 Multiple Languages..........................................................................................45
5.2.8 Layout Based On Values of Individual Fields..................................................45
5.3 Elements of the Request Form..................................................................................45

5.4 Initialization, Input Help, Verification, User Commands.........................................48
5.4.1 Initialization Through Parameterized URL Call...............................................48

5.4.2 Initialization, Input Help, and Verification for Clients in HTML Template....48
5.4.3 Programming BAdIs.........................................................................................48
6. Request Form as Adobe Form......................................................................................48

6.1 Generating an Adobe Form.............................................................................................49
6.2 General Characteristics...................................................................................................50
6.3 Automatic Generation of New Characteristics...............................................................52
6.4 Definition of New Screen Elements on the Form...........................................................52
6.5 Assignment of Form Fields to Characteristics from ISR Customizing (Data Binding). 52
6.6 Testing............................................................................................................................53
6.7 Additional Documentation..............................................................................................53
6.8 Standard and Custom Scenarios with Adobe Forms in the SAP Enterprise Portal........53
7. Processor Determination and Workflow.......................................................................56
7.1 Processing Notifications in a Worklist.....................................................................56
7.2 Processing Notifications in the Workflow................................................................56
7.3 Partner Functions and Partner Determination Procedures........................................58
7.4 Processor Determination from the Standard Role in the Workflow.........................59
7.4.1 Processor Determination for Notifications and Tasks......................................59
7.4.2 Customizing Standard Roles for the Workflow................................................60
8. Costs and Integration with Controlling.........................................................................63

9. Access to Request Forms: Integration of Request Forms in the SAP Workplace or
Existing Intranet or Internet Portals......................................................................................67
9.1 Integrating Request Forms in Existing Intranet Portals or External Portals.............67
9.2 Integration in the SAP Workplace LaunchPad (Single Role Maintenance).............67
9.3 ISR Start Page...........................................................................................................68
9.4 ISR in SAP Enterprise Portal 5.0..............................................................................68
9.5 ISR MiniApps...........................................................................................................70
9.5.1 MiniApp: ISR_MY_NOTI................................................................................70
9.5.2 MiniApps: MA_QM_NOTIFCOM and MA_QM_TASKSCOM....................72
9.5.3 MiniApp : Standard Workflow Inbox...............................................................73
10. Appendix.......................................................................................................................74
10.1 Special Customizing Using Table QISRCONTROL................................................74
10.2 Configuration Settings for Adobe Forms..................................................................75

10.3 Configuration Settings for ITS.................................................................................76
10.3.1 ABAP Workbench (SE80): Settings for ITS....................................................76
10.3.2 Setting Up IACOR to Publish the Internet Service..........................................76
10.3.3 General..............................................................................................................76
10.4 Predefined Request Fields........................................................................................76

10.5 Transporting ISR Scenarios......................................................................................76
10.6 Translating Scenarios and Forms for ITS.................................................................77
10.7 Debugging an ISR Scenario with ITS.......................................................................77
10.8 Catalog Profile, Catalogs, Code Groups, and Codes................................................79
10.9 Standard SAP Activities and Associated Function Modules....................................79
10.10 Methods for Use in the JSP.......................................................................................80
10.11 Notes Relating to ISR...............................................................................................81

1. Introduction
1.1 Main ISR Terms
Internal service requests (internet service requests, ISRs) make it possible for occasional users
to request services in the company intranet, in an extranet, or in the Internet using request
forms that do not require any special knowledge of SAP R/3®.
When a user fills out a request form, a notification is generated in the R/3 system and sent to
the appropriate person by the SAP Business Workflow. This person can execute actions
directly from within the notification (such as sending e-mails, automatically generating and
sending Microsoft Word documents, triggering purchase orders, or starting R/3 transactions).
The request forms and the workflow can be configured individually based on the service
requests and the conditions in the company. Custom ISR scenarios can be created quickly and
easily. Close integration with Controlling and Easy Cost Planning (ECP) enables complex
scenarios in which costs are calculated automatically and allocated directly to the cost objects.
Note:
In the past, internal service requests (ISRs) were also called Internet service requests. ISRs
are now called internal service requests to distinguish them from the Web requests in CRM.
Web requests in CRM are similar to ISRs, but are intended more for requests coming from
outside the company.
1.2 Prerequisites
To be able to use ISRs with the ITS forms, you need SAP R/3 release 46C or later. SAP
strongly recommends that you install Release 46C Support Package 15, since it contains
important new developments for the ISR. You can use the ISR based on ITS technology or in
the SAP Enterprise Portal 5.0 in Java technology. With mySAP ERP 2004 you can define an
interactive form in Adobe PDF. You need the SAP Enterprise Portal for this as well.
To be able to use ISRs in the SAP Enterprise Portal, you need the business package Manager
Self-Service (MSS). To use interactive Adobe forms, you need mySAP ERP 2004 plus Adobe
Reader 6.0.2 or higher. You also need at least SAP NetWeaver '04 SP 7.
You need to either set up an ITS for the R/3 system or implement the Enterprise Portal with
the corresponding Java runtime environment. To access the request forms, you need a Web
browser such as Internet Explorer or Netscape Navigator. You need to have information on
your ITS installation (URL for accessing Internet services and the destination for publishing
them), or the information needed for implementing a Java iView in SAP Enterprise Portal 5.0.
Note also the following changes regarding the ISR that result when WAS 6.40 is used: To
continue to use existing ITS forms, you need a separate ITS server 6.20. The integrated ITS
server of WAS 6.40 cannot be used. It is no longer possible to generate new ITS services with
mySAP ERP 2004.

2. Getting Started – A Simple Example
1.3 Example Scenario: Applying for a New System User
The following example scenario can currently be used only for the Adobe and ITS versions of
the ISR. You customize the ISR scenarios in the same way for both the ITS and the Enterprise
Portal. As shown in the following, you can generate a new ISR scenario from ISR
Customizing. However, for technical reasons it is currently not possible to generate an ISR
view (portal technology) in the same way (see section 2.5). The current procedure for defining
new custom ISR iViews is described in section 5.
The following is an example scenario that provides an introduction to the ISR. Following this
section step by step will give you the basic skills needed for creating and implementing
scenarios. This section is an overview and does not provide a complete description of the ISR
functions. See the later sections for comprehensive information on specialized functions.
The example scenario supports requests for new users in your IT systems. A simple request
form should be available in your intranet in which users only need to enter a user name and
the system. Submitting this form generates a notification that is forwarded to the system
administrator for processing.
1.4 General Scenario Data
The Customizing transaction for the ISR is QISRSCENARIO (SAP reference IMG:
Application Specific Components  Internet/Intranet Services  Internal Service Request 
Scenario Definition  Define Scenarios). This is where you enter general details for the ISR
scenario. You can easily go from here to all Customizing settings. Start the transaction
QISRSCENARIO, choose New Entries on the screen that appears, enter the name and
description of the scenario, the notification type of the notification generated by the request,
and the contact person for the scenario and their role. You can use the values from the
following screenshot (enter your own user name instead of MUSTERMANN). If notification
type 02 is not in your client, import the standard notification Customizing from client 000
with transaction QISR_SM29. To enable end users to find the new ISR scenario, include
relevant key words such as "new user" or "system" in the long text for the search help.

1.5 Defining Characteristics for the Form
Next you need to define the special characteristics (required entry fields on the request form).
The example uses the characteristics SYSTEM and NEW_USER. These characteristics will
later appear on the request form with the specified name as entry fields.
Select Entry Using Form as the entry type in the Web, and then go to the Characteristics
folder to create the two characteristics (New Entries). You can use the characteristic names,
types, and descriptions from the following screenshot, or use your own.

1.6 Defining Tasks for the Notification
When a user submits a request form, a notification is created automatically. If more than one
processor will work on the request, you can assign more than one task to the notification. The
notification is then a container with the individual tasks to be processed. (If you want to
define ISR scenarios without tasks, see section 5.4 for information on finding a processor
when using a notification without tasks). In our example we will create just one task. Create a
new task (New Entries) and enter a description for it. The task will be assigned to a particular
processor in this example (enter your own user name instead of MUSTERMANN).
1.7 Generating the Form (ITS Version)
Next you need to generate an Internet service for the request form based on the Customizing
settings you made. Return to the Basic Data view. Enter a name for the Internet service
(starting with Z) and choose the red-and-white Generate symbol. To create a request form
with the standard SAP design, select Generate (SAP Design). If you want to design the form
yourself later on, select Generate (Plain HTML). An Internet service is automatically
generated and displayed in the ABAP Workbench (in Theme 99  Template SAPLQISR 110
you can see the HTML template that was generated, which you can modify as needed. You
can also find your two characteristics here.) Now all you need to do is publish the Internet
service on the ITS. Right click on the Internet service name and choose Publish  Whole
Service (use the following menu to check that your system or the ITS generation are set up
correctly first: Utilities  Setting  ITS. For more details, see the Appendix in section 8.2).
Return to the basic data view with Back. Save the scenario.

1.8 Generating the Adobe Form
Next you need to generate an Adobe form for the request form based on the Customizing
settings that you made. Return to the basic data view. For the entry type in the Web, choose
Entry Using Adobe PDF. Choose the red-and-white Generate symbol. Choose the option
Without Template. You will now be prompted for a package twice – for the form and for the
interface. You can enter any customer package here. An Adobe form is now generated
automatically and displayed in the Adobe Designer (can also be accessed with transaction
SFP). You can modify the form as needed. To add your two characteristics to the form:
On the right side of the screen in the Library on the Standard tab, choose Text Edit (for
example), select it with the mouse, and drag it to the Body Page. You then need to create a
data link (data binding) to your characteristic NEW_USER. To do this, select the entry field
generated in the layout, and in the window Object  Binding choose the NEW_USER field
with the possible entries function. You can also open the NEW USER field on the left side of
the screen in the Data View and drag FIELD to the New User field. In the Default Binding
attribute of the tab Object  Binding, the linkage of the characteristic from ISR Customizing
to the field is specified in the form with the format $record.NEW_USER.DATA[*].FIELD.

Repeat the whole procedure for the SYSTEM characteristic. Save the form and exit the
Adobe Designer with Back (F3). The technical linkage of the form Z_ISR_FORM_RU01 has
now been inserted in the Form field. You can start the form directly with the test function
(caliper symbol to the right of the Form field - see section 6).
1.9 Costs
For this simple example, we will not look at any costs (checkbox The scenario incurs costs is
not activated). If you activate this indicator, several fields that control the integration of costs
are displayed. See section 8, Costs and Integration with Controlling for all necessary
information on integration of the ISR with costing.

1.10 Running the Scenario
Before you run the scenario, make sure that you have entered your address data in transaction
SU52, since this information is needed by the request form.
1.10.1 Applicant with ITS Scenario
If you use the SAP Workplace, bring up the ISR start page under Employee Self-Service 
Internal Service Request. Enter key words in the text field (such as "need user"), then choose
Solutions. The system displays a list of documents and ISR request forms that contain the key
words you entered. Your new request form for a new user should also appear in the list.
(Recall that you entered the relevant key words for this request form in Customizing.) Bring
up the request form by clicking on the link.
Note: If you are not using the SAP Workplace, you can also access the start page directly from
the Web browser:
http://<your ITS server port>/QISR/!
The form can be accessed directly from the Web browser as well. The syntax for accessing a
scenario with scenario key XXXX and the corresponding Internet service ZYYYY is as follows:
http://<Ihr ITS Server Port>/ZYYYY/!?~okCode=CREATE&scenario=XXXX
Once you have accessed the request form, you can see that it displays the two special
characteristics (SYSTEM and NEW_USER) from the ISR scenario, as well as the address
data of the applicant and the person who entered the data. Fill in these forms and enter
additional text in the lower text field. Now submit your request. The system then informs you
that the notification has been created and indicates the notification number. If you click on
Select new service request (only for forms in the standard SAP design), you return to the ISR
start page and can follow up your request status by choosing Overview of my requests to date
(corresponds to the status of notification processing). The functions provided by the status
monitor are also available as a separate MiniApp, which you can combine with the workplace
or existing Internet or Intranet portals (see section 7.4, ISR MiniApps).
1.10.2 Applicant with Scenario in Enterprise Portal (Adobe Form)
The ISR form can be accessed with contextual information (that is, data of the current
application is transferred to the form) or without contextual information.
If you want to access the form without contextual information, define an iView on the basis of
the master iView Internet Service Request (Adobe) for your Enterprise Portal. For the
parameter ISR Scenario of your iView, specify the technical name of your scenario (such as
RU01).
If you want to access the form with contextual information, insert the scenario into existing
scenario groups (such as scenarios for the Equipment Monitor). To do this, modify the
suitable scenario group in the IMG under Cross-Application Components  Internet/Intranet
Service  Internal Service Request  Scenario Definition  Define Scenario Groups. These
scenario groups are used in the corresponding Web Dynpro applications in SAP Enterprise
Portal to access the desired ISR forms.

See also the documentation on the Web Dynpro applications that you can find in the SAP
Library in the SAP Help Portal (http://help.sap.com) under mySAP Enterprise Resource
Planning  SAP ERP Central Component Cross-Application Components  Manager
Self-Service.
1.10.3 Administrator
Now put yourself in the position of the system administrator, who has just received a new task
for processing. Start transaction IQS9 (Office  Notification  Worklist  Tasks). Choose
My worklist: My tasks with the option To be processed by me and then choose Execute. The
system displays a worklist containing the tasks for you to process.
Select a task and choose Display task. You then see the request data that you entered in the
request form, along with a short description of the task. If you want to see the original form,
choose Display form in the action box on the right-hand side. You can also use the
Notification pushbutton (extended) to go to the notification view and see the request form on
the Form tab. (Normally the request fields are displayed in a tabular view here, but you can
display the original form if you want. See Appendix 8.1). As the system administrator, you
can now create the user in the system. It is possible to provide the system administrator with
direct access to the corresponding transaction from the action box with the corresponding
defaults. Section 3.4 provides comprehensive details on the action box. When the new user
has been created, the processor can close the task and the notification. by choosing Change
Task in the menu and then choosing the following pushbuttons in order: Release Task 
Complete Task  Task Successful  Save. To return to the notification view, choose
Notification (Extended). There you can release, close, and save the notification.
When you have returned to the ISR start page, you can see that your request has been
processed successfully under See Overview of My Requests to Date.

1.11 Checklist for New ISR Scenarios
Before you create an ISR scenario, you need to consider the following factors:
 What is the overall process that needs to be supported?

 Which fields (characteristics) should appear on the request form? (ITS scenario: If you
want checkboxes or radio buttons, generate a reference first, with normal entry fields.
Then modify the Internet service afterwards. F4 help with dropdown boxes can also be
created by means of subsequent modification of the Internet service.)
 Do you want to use the workflow for processing notifications, or should processors select
notifications from a worklist?
 Is an approval step necessary? If so, use notification type 01, otherwise use 02.
 Will more than one processor be working simultaneously? If so, you need tasks. If the
processors can work in sequence, you do not need tasks.
 What criteria should be used to determine the processor? Will processors be permanently
assigned to tasks? Or will the processor be selected based on criteria such as request
fields, organizational structures, costs, or the applicant's last name?
 What actions (starting transactions, answering e-mails, and so on) should be provided in
the action box for the processors?
Once you have clarified these points, you can start creating the ISR scenario. The following
sections provide detailed information on all related subjects.
We wish you every success and hope you enjoy creating your new scenarios!

3. Basic Customizing
Transaction QISRSCENARIO is the central Customizing transaction for the ISR, where you
can make all settings for creating a new ISR scenario. When you start the transaction, the
existing ISR scenarios are displayed. You can access these by double-clicking on them.
1.12 General Details
 Scenario key: The key for the scenario must not be in the SAP (S*) namespace.
 Scenario active: Only activated scenarios are available. With mySAP ERP 2004 you can
specify a validity period during which new requests can be submitted by the applicant.
Requests that have already been submitted can, of course, still be approved and processed
after expiration of this period.
 The Description is used as the title for the form.

 You can find the corresponding form using key words on the ISR start page by using the
Long Text for the search help. For more information on the search engine, see the SAP
Library under Accounting  Controlling  Cost Center Accounting  Information
System  Online Information System  Searching for Documentation on Reports 
Searching for Documents Using the Retrieval System.
 The notification type determines whether the notification scenarios require approval, and
if so, defines how the approving manager is determined. In addition, you can use the
notification type to define the layout for the notification transaction. For most scenarios,
you can use notification type 01 (requires approval) or 02 (does not require approval). If
you want to create your own, individual application using the ISR framework that will
contain many scenarios, it is recommended that you copy notification type 01 or 02 and
create your scenarios using your own notification type (Customizing under Cross-
Application Components  Internet/Intranet Services  Internal Service Request 
Prepare General Notification  Notification Creation  Notification Type  Define
Notification Type). If notification types 01 or 02 are not in your client, you can use
transaction QISR_SM29 to transfer the settings for notification types 01 and 02 from
client 000 to your client. You then need to edit the number ranges of the notification type
in Customizing under Cross-Application Components  Internet/Intranet Services 
Internal Service Request  Scenario Definition  Prepare General Notification 
Notification Creation  Notification Type  Define Number Ranges.
 The contact person for the scenario must be an R/3 user. The contact person is only
responsible for the technical aspects of the scenario, not for questions regarding the
content of internal service requests. A feedback button appears on the request forms,
which triggers an e-mail to the contact person. The contact person is stored in the
notification in the system if you select Partner role contact.
1.13 Request Entry Type
Use the entry type to control how your request is entered:

 Text Entry Only
Free text entry without a form.
 Entry with form (up to Release 4.70)
Entry with ITS service. You can define special characteristics and must enter an
Internet service.
 Entry Using Notification Transaction
Entry with the usual SAP entry screen for general notifications (HTML-GUI).
 Entry Using Adobe PDF
You can define special characteristics here. You can generate the Adobe form or (if it
already exists) enter it directly.
 Entry Using JSP iView
You can define special characteristics here. You can generate the JSP form or (if it
already exists) enter it directly.
 Entry Using BSP
You can define special characteristics here and must assign a BSP application. It is
currently not possible to generate the BSP application.

You can only define special characteristics (and thus an individual request form) if you have
selected the entry type Form Entry, Entry Using Adobe, Entry Using JSP iView, or Entry
Using BSP.
1.13.1 Entry Using ITS Service
You enter the request using an HTML form specially designed for the scenario. An Internet
service must be assigned to the scenario. This service must contain the HTML templates and
language-dependent resources required for the request. You can assign an Internet service to
only one scenario.
To create a new Internet service for your ISR scenario, choose Generate. A dialog box
appears with three options:
 With template:
An existing Internet service is copied. The advantage here is that the complete layout of
the copied service is transferred. The disadvantage is that the characteristics of the new
scenario then need to be inserted manually in the HTML template.
 Generate (SAP Design):

A new Internet service is generated based on the template service SR00. This service has
the SAP standard design which is used in all R/3 transactions. An Internet service created
in this way contains all input and output fields required for immediate testing of the
scenario. The system inserts a request data area containing the corresponding entry fields
for characteristics that were defined in the scenario specifically for the request.
 Generate (Plain HTML):

A new Internet service is created based on the template service SRPH. This service has a
simple design that uses standard HTML elements almost exclusively, and is intended to be
set up individually by Web designers. The generated Internet service contains all
entry/output fields required for immediate testing of the scenario definition. The system
automatically inserts a Request Data area (with the corresponding entry fields) for the
request-specific characteristics defined in the scenario.
Notes:
- Before you can test the Internet service, you must publish it manually. You are
automatically taken to the editing mode of the Internet service in the Development
Workbench, where you can publish it (right-click on the Internet Service  Publish 
Complete Service). You can then test the ITS service from within scenario customizing
(test symbol after the Internet service).
- If you want to test the Internet service directly in transaction SE80, right-click on the
Internet service and choose Start Service. Since this does not set the parameters for the
URL, a screen is displayed once you have logged on in which you enter the scenario key
in capital letters, and then choose Create. (You can also complete the URL in the Web
browser (such as with Internet service ZRU01 and scenario key RU01:
... scripts/wgate/ZRU01/!?~okCode=CREATE&SCENARIO=RU01)
If you add new characteristics in Customizing later, this does not influence an Internet
service that has already been generated. Insert the new characteristics manually into the

existing HTML template, or generate the Internet service. Caution: When you generate the
service, you lose any manual changes you may have made to the HTML template.
- If you want to use form elements such as dropdown list boxes, checkboxes, or radio
buttons instead of the simple entry fields generated automatically in the HTML template,
you can redefine these elements in the HTML template based on the examples in section
4.3.
1.13.2 Entry Using Adobe PDF
You enter the request using an Adobe form in PDF format specially designed for the scenario.
A form must be assigned to the scenario for this purpose. A form can be assigned to more
than one scenario, but the characteristics of the different scenarios must be the same.
You can assign an existing Adobe form to the ISR scenario or generate a new form.
Generating an Adobe Form
You can enter a name for the form in the form field. The form generation process creates a
form with that technical name. If you leave the form field empty, the system generates a form
with the name Z_ISR_FORM_<scenario> (such as Z_ISR_FORM_Z123 for scenario Z123).
To create a new Adobe form for your ISR scenario, choose Generate. A dialog box appears
with three options:
 Without Template:
A new empty Adobe form is created. The characteristics of the scenario are transferred to
the data part of the form and are available on the body page of the form layout for data
binding of the fields and form elements to be defined.
 With Template (from Scenario):

An existing Adobe form is copied. In addition to the characteristics of the new scenario,
the characteristic of the template scenario are transferred to the data view data container of
the new form and the new interface.
 Generate Form (SAP Design):

A new Adobe form is created based on the template ISR_FORM_SCENARIO. This form
has the SAP standard design used in all standard scenarios. The form contains various
graphical elements that you can use as a template for your own fields and elements on the
form. You can also use the ISR Controls library. To find out how to obtain this library, see
Note 741381 (it is planned to ship the ISR Library with the SAP GUI in the future).
1.14 Entry Using JSP iView
You enter the request using a JSP iView form specially designed for the scenario. To do this,
you enter an iView in the Portal Component field in ISR Basic Customizing of the scenario
with the Additional Data for Scenario pushbutton. See section 5.
Using the Generate iView pushbutton next to the Portal Component field, you can generate an
iView that contains all characteristics as input-ready fields. The generated iView is saved on

your local PC. For information on how to import this *par file into your Enterprise Portal, see
section 5.1 (point 4. ff).
1.15 Entry Using BSP
If you use this entry type, you must specify a BSP application. An example of a BSP
application is ISR_DEMO1. This application uses the class
CL_ISR_BSP_RUNTIME_CORE. To define your own BSP application on the basis of the
ISR, you can use the BSP application mentioned above (ISR_DEMO1) as a template.
1.16 Flow Logic with BAdI Implementations
The Business Add-In button displays the BAdI Builder. You can program four BAdI methods
(customer exits) for your scenario to create initializations, F4 help, entry checks, and
additional events (buttons) for your request form. Section 4.4.3 explains the programming
methods for BAdIs in detail. You can also use the existing BAdIs from another scenario with
the second radio button Use Business Add-In from Scenario.
1.17 Characteristics
You define the required entry and output fields for the request form in scenario customizing
as Characteristics (double-click on Characteristics).

The following types of characteristics are available:
 Characteristics referring to a dictionary type = Data element

 Characteristics referring to a dictionary type = Structure
 Uncategorized characteristics
The characteristics can be valuated on the HTML template under the characteristic name
specified here. The only exceptions are characteristics referring to a structure. In this case,
the structure fields can be used with their field names without a structure name (<structure
name>-<field name>) in the HTML template. That is, structures are always resolved for the
request and can thus be seen as having a more compact definition instead of being a series of
characteristics that reference data elements.
The characteristic name specified in Customizing is displayed on the request form as a field
label. Categorized characteristics can use the field length in addition. For characteristics that
reference data elements or structure fields, input/output formatting (as with screen fields) is
executed as well, including type checks.
Uncategorized characteristics have the implicit category CHAR250 without input/output

conversion.
The following restrictions apply to the definition of the scenario characteristics:
 Characteristic names or structure field names must be unique in the scenario.

 Characteristic names or structure field names must not begin with "ISR_".
 Characteristic names or structure field names should not be named in the same way as
the HTML business indicators LABEL, NAME, VALUE, DIM, MAXSIZE, TYPE,
EXISTS, ENABLED, or VISSIZE.
 The maximum length of the characteristic names or structure field names is 28
characters.
 The maximum data length of the characteristic names or structure field names is 250
characters.
 The maximum length of the characteristic name is 40 characters.
In addition to characteristics you define yourself, an entire range of standard characteristics is

provided which are automatically initialized and can be displayed on the request form (such
as entered by or applicant). The implemented standard characteristics that are only output
fields are listed in the appendix.
If you use Adobe forms, you may have to make additional settings for each characteristic:
 The characteristic should contain programmed input help. You must specify on the
characteristic the technical name you are using for the key value and the default value
in the programming of the BAdI method (see section 4.4.3). The following screenshot
is an example.
 The characteristic should be displayed as a multiline long text field. It should be
possible to enter a body text, in which case you choose Long Text Field. (Note that the

ISR framework already provides such a field: the general field
ISR_NEW_LONG_TEXT.)
1.18 The Action Box
1.18.1 Overview
The action box contains a toolbox for the notification processor for processing the request (for
example, you can send a generated e-mail, start a parameterized transaction, call R/3 BAPIs
for creating or changing business objects in R/3, or generate Word documents – all at the
touch of a button). Since request data is known in the ISR framework, the processing steps
can largely be left to the system. The processor's main task is to check the request or complete
the request data and then trigger the processing transactions. This eliminates the need to
manually transfer request data, which saves time and reduces errors.
The ISR framework provides several standard actions that you can use immediately (such as
display/change form or start parameterized transaction. For a complete list, see appendix 8.9).
For special requests, you can implement the corresponding function modules that
automatically process the request data as required. The action box is thus the integrating link
between the request form and R/3.
1.18.2 Defining the Action Box
To edit the actions, choose Action Box. Actions are always defined for one notification type
and can be used specifically for ISR scenarios of this notification type. Choose New Entries
and enter a key and the action name. Enter the notification type that you used in your
scenario.
In the Control section, enter the following:
 Scenario controls the visibility of the action in each scenario that belongs to a
notification type. (Make the required entries first: Sort sequence, icon, and As
documentation: None and choose ENTER to see the F4 help for the scenarios.)
 Sort number controls the order in which the actions are displayed in the action box.
 Use in controls the visibility of the actions in the notification. The default is All views
(create, change, display).
 and controls the visibility in notifications and/or tasks. The default is Notification and
task.
 Documentation defines whether a performed action is documented in the notification
(for the sake of simplicity, choose None).
In the Function section, you can specify the name of the function module that is processed
when the action is accessed. Several examples of these types of function modules are included
in the standard system (see appendix 8.9).
The business transaction controls the notification status in which the action is allowed to be
triggered, and the status of the notification once the action has been successfully completed.
In the Interface section, you specify the icon and text that appear in the action box.

In the Rules section, you specify the sequence and dependencies for carrying out the actions.
If you have selected the task or action option under documentation, two additional sections
are displayed for task or action coding. The coding enables you to make specific evaluations
and selections using special codes. For example, you can use transaction IQS9 to select all
tasks that have a certain code. Enter SAPISR as the code name, and select a code from the F4
help from the list of codes already defined for the SAPISR code group. If you want to extend
the codes for the code group SAPISR or create your own code group, see appendix 8.8.
1.19 Tasks
When you submit an ISR request form, a notification is created in R/3. If your scenario
requires that the request be processed by multiple users simultaneously, you can assign
multiple tasks to the notification.
If the request only needs to be processed by one user at a time, you do not need tasks. In this
case, the notification is simply forwarded to the next processor after each step is completed.
If you want one or more tasks to be created automatically when the notification is created,
choose Tasks in scenario customizing. The task is automatically assigned a sequential
number. Enter a name for the task. The assignment of a key (such as a code group) can be
used later to evaluate or select the tasks. This means you can select all tasks with a certain
code, for example, using transaction IQS9. Enter SAPISR as the key (or code group). In the

next field, you can use F4 help to select one of the codes already defined for the code group
SAPISR. If you want to extend the codes for the code group SAPISR or create your own code
group, see appendix 8.8 for more information.
There are two alternative fields for selecting the processor for the task:
 A manager: This can be a registered user in the system (partner function: task processor)
or the responsible department (partner function: responsible department). The manager
entered is the task processor.
 The standard role for the workflow enables flexible processor determination. The task
processor can be selected based on the input values on the request form or on information
such as the cost center of the person entering the request. (see section 5, Processor
Determination and Workflow).
4. The Request Form as an Internet Service (ITS Technology)
1.20 Setting Up an Internet Service for the ISR
The automatic generation of an Internet service for an ISR scenario creates four HTML
templates under Theme 99. (It does not matter whether the Internet service is generated in
SAP Design or Plain HTML):
 SAPLQISR3 110: Template for creating a request

 SAPLQISR3 120: Template for changing a request
 SAPLQISR3 130: Template for displaying a request
 SAPLQISR3 200: Template used as a confirmation after the request has been
submitted

In the standard configuration, the templates for the change and display modes are based on
the template for the create mode (SAPLQISR3 110). This means that all templates have the
same layout. If you want to modify the layout, you only need to change template SAPLQISR3
110.
The fields in the request are automatically set to ready for input where appropriate for the
mode. In the create mode, all fields are ready for input. In the change mode, only the fields
that have been created as characteristics are ready for input (unlike the general ISR fields,
which can only be changed using the notification transaction because they are closely
integrated with the notification). In the display mode, none of the fields are ready for input.
(Technically, all templates are directly linked to screens 110, 120, and 130 in transaction
QISR1, which controls the flow logic of the request form and which fields are ready for
input).
Template SAPLQISR3 200, which displays a confirmation when a request form has been
successfully submitted, defaults to template ISR_STATUS_MESSAGE_1 (or
ISR_STATUS_MESSAGE_1_PLAIN_HTML for Plain HTML) of the Internet service
SR_LIBRARY. If you want to use your own layout for the confirmation, copy template
SR_LIBRARY to template SAPLQISR3 200 and then modify the copy.
Notes:
 Do not change Internet service SR_LIBRARY, since it contains the function library for all
ISR scenarios.

 Always enter Internet services in the original language, otherwise problems may arise due
to language dependency. For requests in different languages, use the text elements in the
HTML templates (such as #INFO), whose contents you can define in the original
language in the THEME of the Internet service. You can translate the texts using
transaction SE63.
1.21 Layout Options for the Request Form
The ISR framework is designed to ensure as much freedom as possible when creating request
forms, and at the same time to include as many standard requests as possible. Therefore, an
Internet service is created for each ISR scenario. You can modify these Internet services as
needed. The layout options are described below, starting with the most basic.
1.21.1 SAP Design or Plain HTML
When you generate an Internet service for your ISR scenario, the system displays a dialog box
with three options:
 With template: An existing Internet service is copied. The advantage here is that the
complete layout of the copied Internet service is transferred. The disadvantage is that you
have to manually enter the characteristics for the new scenario in the HTML template.
 Generate (SAP Design): A new Internet service is created based on the template service
SR00. This service has the standard SAP design that is used in all R/3 transactions.
Choose this option if you want to use the SAP design for your ISR scenario.
 Generate (Plain HTML): A new Internet service is created based on the template service
SRPH. This has a simplified layout with mostly standard HTML elements, and is
designed to be individually modified by Web designers. Choose this option if you want to
use your own design, such as for an external enterprise portal.
1.21.2 Different Layouts Enabled by Additional Themes
Themes enable you to use more than one design or layout variant of a request form at a time.
For example, you can create a new theme with the corresponding HTML templates if your
ISR request form is used on a handheld device or WAP cell phone. You can enter the required
theme when you access the URL (example: .../RU01/!?
~okCode=CREATE&SCENARIO=RU01&~theme=88).
1.21.3 Different Layouts for Different Request Modes (Create/Change/Display)
If you want to have different layouts for the various request modes that differ in more than
just which fields are ready for input, you have two options:
 Each template provides you with the parameter ISR_MODE in the Business HTML
environment. Depending on the mode, this parameter has the value CREATE,
CHANGE, or DISPLAY. This enables you to have a change button, for example,
displayed in the change mode as follows:

ìf ( ISR_MODE == "CHANGE" );`
<input type="submit" name="BUTTON_SAVE" … >
ènd`
 If the layouts are very different, you can delete the reference to template SAPLQISR3
110 and enter your own independent HTML code for templates SAPLQISR3 120 and
SAPLQISR3 130.
1.21.4 Layout Based On User Role
It is often the case that the processor needs to have more request fields than the users who
enter the requests. You can achieve this by using the parameter ISR_FORM_VIEW within the
Business HTML environment. This parameter has the value ISR_REQUEST as a default. It
only has the value ISR_PROCESS when the request form is accessed by the processor. You
can have an extra field displayed for the processor as follows:
ìf ( ISR_FORM_VIEW == "ISR_PROCESS" );`

<input type="text" name="COLOR" … >
ènd`
You can also set the parameter ISR_FORM_VIEW within the BAdI methods based on rules
that you define, and thus control the layout more exactly.
1.21.5 Page Layout and Scrolling Logic
You can use the ISR framework to define request forms with multiple pages for a more
structured entry of data (if necessary, you can display the entries made on the previous pages
on the final page). Forms with multiple pages are defined as follows:
Only the page structure is defined on the main template (such as SAPLQISR3 110). For a
three-page form:
ìf ( ISR_PAGE == “1” )`
ìnclude(~theme="99", ~language="", ~name="page1.html")`
èlsif ( ISR_PAGE == “2” )`
èlsif ( ISR_PAGE == “3” )`
ènd`
The standard parameter ISR_PAGE determines the current page. The page templates
themselves are used as includes. Each of these templates has a new HTML template in the
Internet service.
You can scroll by means of a button which triggers one of the standard ISR commands:
NEXT_PAGE: One page forward
PREV_PAGE: One page back
<input type="submit" value="Seite vor" onclick="SAPEvent('NEXT_PAGE')" … />
<input type="submit" value="Seite zurück" onclick="SAPEvent('PREV_PAGE')" … />
When one of these commands is triggered, the number of the current page (parameter
ISR_PAGE) is automatically incremented or decremented by one. If a more complex

scrolling logic is required (for example, depending on the entries made on the page), you can
explicitly set the value of the parameter ISR_PAGE in the BAdI methods.
1.21.6 Layout Based On Values of Individual Fields
You can have fields displayed based on the values in individual fields (show PROJECT and
ORDER):
ìf ( PROJECT == "XYZ" && ORDER == "" )`

`SAP_ISRField(name="CO_AREA")`
ènd`
Or you can switch the ready-for-input/output status:

ìf ( ORDER == "XYZ" )`
`l_mode = "disabled";`
èlse`
`l_mode = "enabled";`
ènd`
`SAP_ISRField(mode=l_mode, name="CO_AREA")`
1.22 Elements of the Request Form
Each of the form variants (SAP standard design and Plain HTML) has a special ISR library
that defines all form elements supported by HTML (entry field, dropdown list box, radio
button, checkbox, text entry field) for the ISR framework. These libraries also provide
additional help functions for grouping and positioning the request elements. For a complete
description of the ISR Library, see the SAP Library under Cross-Application Components 
Internal Service Requests  Preparing the Internal Service Request  Definition of an
HTML Form  Define Form  Examples: Specific Form Elements in HTML Templates
(SAP Design and Plain HTML).
1.22.1 SAP Design with Business HTML
 Input field (one row) for the characteristic COLOR:

`SAP_ISRField(name="COLOR", size=30)`
 Dropdown list box (input help) for the characteristic COLOR:

You can create the value list for a dropdown list box directly on the template (alternatively
you can use the BAdI method SCENARIO_SET_ADDITIONAL_VALUES).
`COLOR_Option[1] = "red";
COLOR_Option[2] = "green";
COLOR_Option[3] = "blue";
COLOR_Label[1] = "you like the red color?";
COLOR_Label[2] = "or the green color?";
COLOR_Label[3] = "or the blue color?";`
`SAP_ISRPulldownField(name="COLOR", key="COLOR_Option", fieldLabelWidth=20,

content="COLOR_LABEL", size=30)`

 Checkbox for the characteristics COLORRED, COLORGR, and COLORBL:
`SAP_ISRCheckBox( name="COLORRED", left=4, top=0,labelWidth=10 )`

`SAP_ISRCheckBox( name="COLORGR", left=4, top=0,labelWidth=10 )`
`SAP_ISRCheckBox( name="COLORBL", left=4, top=0,labelWidth=10 )`
 Radio button for the characteristic COLOR:
`SAP_ISRRadioButton( id="11", name="COLOR", value="red", text="you like the red

color?", left=4, top=0, labelWidth=0 )`
`SAP_ISRRadioButton( id="12", name="COLOR", value="green", text="or the green
`SAP_ISRRadioButton( id="13", name="COLOR", value="blue", text="or the blue
 Text field (multiple rows) for the characteristic MYTEXT:
`SAP_ISRTextArea( id="MYTEXT", type="SAP_WEBGUI", name="MYTEXT", cols=80,

rows=4, left=1, top=6 )`
 Predefined standard text fields ISR_NEW_TEXT and ISR_TEXT

The ISR has a standard text field, the contents of which are automatically transferred to
the notification long text. If an additional comment is entered by the person entering the
request or by the person processing it, the comment is added to the notification long text.
You can also insert an automatic log row with the date, time, and user in notification
customizing in the SAP reference IMG under Cross-Application Components 
Internet/Intranet Services  Internal Service Request  Scenario Definition  Prepare
General Notification  Notification Processing  Overview of Notification Type
Format Long Text. New comments are entered in the text field ISR_NEW_TEXT, while
old ones are displayed in the text field ISR_TEXT:

`x = 1; y = 19;`
ìf ( ISR_mode == "CREATE" );`
`SAP_ISRGroupBox(x , y , 069, 005, #comment)`
`SAP_ISRLongTextInput(cols=67, rows=5, left = x+1, top = y+1 );`
`y = y + 6;`
èlseif ( ISR_mode == "CHANGE" );`
`SAP_ISRLongTextOutput(cols=67, rows=7, left = x+1, top = y+1, height=5);`
`SAP_ISRLongTextInput(cols=67, rows=5, left = x+1, top = y+6 );`
`y = y + 11;`
èlse;`
`SAP_ISRLongTextOutput(cols=67, rows=5, left = x+1, top = y+1 );`
`y = y + 6;`
ènd;`
 Buttons
The standard buttons for submitting, changing, and checking are defined as follows:
`SAP_ISRStandardButtons( left=1 , top=20, buttonWidth=018 )`

The following shows how to create the button for a freely definable user command (or
page scrolling), which can be evaluated in the BAdIs:
`SAP_ISRUserButton( buttonLabel="Calculate here",
quickinfo="Calculates the price of the order",
okcode="CALC", id="CALC", left=1 , top=30 )`
 Positioning
All ISR functions normally use an absolute positioning of the elements on the request
form. You can use the functions SAP_ISRFieldListBegin()(for list-type layout) and
SAP_ISRFieldListRowBegin() (for column layout) to group and position entry fields:
`x = 1; y = 1`
`SAP_ISRFieldListBegin( x , y ,018) `
`SAP_ISRField( name="ISR_INITIATED_BY-FIRSTNAME" ) `
`SAP_ISRFieldListRowBegin( ) `
`SAP_ISRField( name="ISR_INITIATED_BY-TEL_NUMBER" ) `
`SAP_ISRLabel( labelText="-", left = x+23); `
`SAP_ISRField( name="ISR_INITIATED_BY-TEL_EXTENSION",
fieldLabel="noLabel", left=x+22 ) `
`SAP_ISRFieldListRowEnd( ) `
`SAP_ISRField( name="ISR_INITIATED_BY-E_MAIL" ) `
`SAP_ISRField( name="ISR_INITIATED_BY-DEPARTMENT" ) `
`SAP_ISRFieldListEnd( ) `
1.22.2 Plain HTML
Unlike the SAP design variant, Plain HTML variants use as few SAP and ISR proprietary
business HTML constructs (blue font) as possible.
 Positioning
Each form element is laid out and positioned using normal Web design methods (tables,
transparent GIFS, and so on).
 Name of characteristic COLOR:
`getLabel("COLOR")`
 Entry field for characteristic COLOR:
<input name="COLOR" value="`COLOR`" type="text" size="20" `disabled("COLOR")`>

You can create the value list for a dropdown list box directly on the template (alternatively
you can use the BAdI method SCENARIO_SET_ADDITIONAL_VALUES).
`COLOR_Option[1] = "red";
COLOR_Option[2] = "green";
COLOR_Option[3] = "blue";
COLOR_Label[1] = "you like the red color?";
COLOR_Label[2] = "or the green color?";
COLOR_Label[3] = "or the blue color?";`
<select id="COLOR" name="COLOR" size="1" `disabled("COLOR")`>

`SetOptions("COLOR","COLOR_OPTION","COLOR_LABEL")`
</select>
Alternatively:
<select id="COLOR" name="COLOR" size=1 `disabled("COLOR")`>
<option value="red" `Selected("COLOR","red")` > you like the red color?
<option value="green" `Selected("COLOR","green")`> or the green color?
<option value="blue" `Selected("COLOR","blue")`> or the blue color?
</select>
 Checkbox for characteristic COLOR with multiple rows:
`CheckboxProlog("COLOR[1]")`
<input name="COLOR[1]" value="red" type="checkbox"
`Checked("COLOR",1,"red")` `disabled("COLOR")`>you like the red color? <br>
<input name="COLOR[2]" value="green" type="checkbox"
`Checked("COLOR",2,"green")` `disabled("COLOR")`>and the green color? <br>
<input name="COLOR[3]" value="blue" type="checkbox"
`Checked("COLOR",3,"blue")` `disabled("COLOR")`>and the blue color? <br>
Or with different characteristics COLORRED, COLORGR, and COLORBL:
`CheckboxProlog("COLORRED")`
<input name="COLORRED" value="red" type="checkbox"
`Checked("COLORRED",1,"red")` `disabled("COLORRED")`>you like the red color? <br>
`CheckboxProlog("COLORGR")`
<input name="COLORGR" value="green" type="checkbox"
`Checked("COLORGR",1,"green")` `disabled("COLORGR")`>and the green color? <br>
`CheckboxProlog("COLORBL")`
<input name="COLORBL" value="blue" type="checkbox"
`Checked("COLORBL",1,"blue")` `disabled("COLORBL")`>and the blue color? <br>
<input name="COLOR" value="red" type="radio" `checked("COLOR",1,"red")`

`disabled("COLOR")`>you like the red color?
<br>
<input name="COLOR" value="green" type="radio" `checked("COLOR",1,"green")`
`disabled("COLOR")`>or the green color?
<br>
<input name="COLOR" value="blue" type="radio" `checked("COLOR",1,"blue")`
`disabled("COLOR")`>or the blue color?
<br>
 Text field for characteristic MYTEXT:
<textarea wrap="physical" rows="5" cols="75" name="`GetTextAreaName("MYTEXT",75)`"

`readonly("MYTEXT")`>`GetTextAreaContent("MYTEXT")`</textarea>
Note: Place the call for GetTextAreaContent directly between > and the </textarea>. This
avoids unwanted spaces at the beginning of the text being entered.
 Predefined standard text fields ISR_NEW_TEXT and ISR_TEXT

request or by the person processing it, the comment is added to the notification long text.
You can also insert an automatic log row with the date, time, and user in notification
customizing in the SAP reference IMG under Cross-Application Components 
Internet/Intranet Services  Internal Service Request  Scenario Definition  Prepare
General Notification  Notification Processing  Overview of Notification Type
Format Long Text. The new comments are entered in the text field ISR_NEW_TEXT,
while old ones are displayed in the text field ISR_TEXT:

ìf ( ISR_MODE != "DISPLAY" );`

<textarea wrap="physical" rows="8" cols="65"
name="`GetTextAreaName("ISR_NEW_TEXT",65)`"
`readonly("ISR_NEW_TEXT")`>`GetTextAreaContent("ISR_NEW_TEXT")`</textarea>
ènd`


<br>
ìf ( ISR_MODE != "CREATE" );`
<textarea wrap="physical" rows="12" cols="65"
name="`GetTextAreaName("ISR_TEXT",65)`"
`readonly("ISR_TEXT")`>`GetTextAreaContent("ISR_TEXT")`</textarea>
ènd`
 Buttons
<input type="submit" name="BUTTON_SEND" value="Absenden" `disabled("BUTTON_SEND")`
onclick="SAPEvent('SEND')">
<input type="submit" name="BUTTON_CHECK" value="Prüfen"

`disabled("BUTTON_CHECK")` onclick="SAPEvent('CHECK')">
The following shows how to create the button for a freely definable user command (or
page scrolling), which can be evaluated in the BAdIs:
<input type="submit" name="B_CALC" value="Rechnen" onclick="SAPEvent('CALC')">

1.23 Initialization, Input Help, Verification, and User Commands
1.23.1 Initialization Through Parameterized URL Call
The fields on the request form can be initialized by means of a parameterized URL call. The
syntax for initializing the COLOR characteristic with RED and the TASTE characteristic with
GOOD is shown in the following example:
…. SCENARIO=MK01&scenario_params=COLOR=RED$TASTE=GOOD
1.23.2 Initialization, Input Help, and Verification for Clients in HTML Template
You can define any initializations, input helps, or verifications directly in the HTML
template. Modify the HTML templates accordingly. If you use the normal JavaScript
methods, the verifications will only take place in the clients and so the performance will be
better. If you use the SAP HTML Business functions as the script language, processing takes
place on the ITS. Performance is as good for initializations and input help as it is in the
JavaScript solution. Where validations are concerned, the client-only JavaScript solution has
better performance. (For input help with SAP HTML Business functions, see section 4.3.1)
1.23.3 Programming BAdIs
1.23.3.1 Methods for ISR BAdIs QISR1: Exits for Form Processing
Using the BAdI definition QISR1, the ISR enables you to control the flow logic for the
request form in R/3 in detail. A total of five BAdI methods are available:

Call ISR
Form
INT_SERVICE_REQUEST_INIT
(only in mode=CREATE)
Initialization
SCENARIO_SET_FORM_VIEW
PBO
SCENARIO_SET_ADDITIONAL_VALUES
User Fills Out

Form
SCENARIO_PROCESS_USER_COMMAND
INT_SERVICE_REQUEST_CHECK
(not in mode=DISPLAY)
PAI
No Check ok
and SUBMIT
form?
Yes
Create/Change Notification
 INT_SERVICE_REQUEST_INIT: Initialization – is run as the first method when a

new request form is called (create mode).
 SCENARIO_SET_FORM_VIEW: Determine form view – is run when a new request
form is called (possibly after BAdI method INT_SERVICE_REQUEST_INIT)
 SCENARIO_SET_ADDITIONAL_VALUES (corresponds to PBO screen): Set
additional values for input help – is run when a request form is called (create, display,
change) before the form is output
Note: In this exit, fill the internal table ADDITIONAL_DATA with values that are
needed by the form at runtime but are not saved in the request. That is, here you can
set value lists for dropdown list boxes (see examples below) and control parameters.
The internal table ADDITIONAL_DATA is not deleted automatically – data is
retained until the form is submitted. The MODE parameter enables you to configure
the logic based on the current mode (CREATE, CHANGE, DISPLAY).
 SCENARIO_PROCESS_USER_COMMAND (corresponds to PAI screen): Process

own user commands – is run first when an event is triggered on the request form
(check, submit, user command)
 INT_SERVICE_REQUEST_CHECK: Check – is run second when an event is
triggered on the request form (check, submit, user command). (The check is therefore
always run before the notification is created.)

 Events on the request form (check, submit, user command) are executed last.
You can create the implementations for the BAdI methods for your ISR scenario as follows:
In the basic Customizing for your ISR scenario, choose Business Add-In which takes you
directly to the BAdI builder for the QISR1 definition. To display a particular implementation
of the BAdI method for a scenario, choose Implementations  Display and double-click on
an implementation. The filter value (with the same name as a scenario) indicates which
scenario the implementation belongs to. It is possible for more than one scenario to be
assigned to an implementation (more than one filter value). Once you have selected an
implementation, you can go to the BAdI methods by double-clicking on the Interface tab. The
program code that is displayed for each method is only run for the scenarios defined by the
filter values.
If you want to create a new BAdI implementation for your scenario, choose Implementations
 Create and enter a name for the implementation. Enter a short description, and enter a
scenario name as the filter value. Save and activate the implementation. You can now
program the desired methods. You must then activate the implementation.
1.23.3.2 Data Structure in the ISR Framework
You can use the following standard ISR data structures for implementing BAdI methods:

Name Category
Description
FLT_VAL QSCENARIO
Current scenario
MODE QISRDMODE
Current processing mode (CREATE, CHANGE, DISPLAY); corresponds to the template parameter
ISR_MODE
FORM_VIEW QISRDFORMVIEW
Current form view (ISR_PROCESS or ISR_REQUEST), corresponds to the template parameter
ISR_FORM_VIEW
PAGE QISRDFORMPAGE
Current page number; corresponds to the template parameter ISR_PAGE
GENERAL_DATA QISRSGENERAL_PARAM
General ISR data (requested by, entered by, priority, notification short text, etc.)
SPECIAL_DATA QISRTSPECIAL_PARAM
Table with special request data that depend on the scenario and that was defined as characteristics in ISR
Customizing. The table has a row for each characteristic, with the column FIELDNAME
ADDITIONAL_DATA QISRTSPECIAL_PARAM
Additional table for input help values etc., which can be used as needed
USER_COMMAND* SYUCOMM
The last command that was triggered on the form
RETURN* BAPIRET1
Return structure for error messages
* only in BAdI method SCENARIO_PROCESS_USER_COMMAND
1.23.3.3 Examples
 Initialization (INIT method) of characteristic NEW_COSTCENTER with the standard

ISR parameter INITIATED_BY-MASTER_CCTR:
* local data
DATA: ls_special_data TYPE qisrsspecial_param.
* loop over special_data

LOOP AT special_data INTO ls_special_data.
CASE ls_special_data-fieldname.
WHEN 'NEW_COSTCENTER'.
ls_special_data-fieldvalue = general_data-initiated_by-MASTER_CCTR.
WHEN OTHERS.
ENDCASE.
MODIFY special_data FROM ls_special_data.
ENDLOOP.
 Output notification when checking (check method):

IF general_data-initiated_by-lastname is initial.
* message e105(qisr).
return-type = 'E'.
return-id = 'QISR'.
return-number = '107'.
EXIT.
ENDIF.
 Process user command CALC (user command method):

data: ls_special_data type qisrsspecial_param.
data: ls_total type i,
ls_monitor(1) type c.
* process user commands

case user_command.
when 'CALC'.
* read special data MONITOR

LOOP AT special_data INTO ls_special_data.
CASE ls_special_data-fieldname.
WHEN 'MONITOR'.
ls_monitor = ls_special_data-fieldvalue.
WHEN OTHERS.
ENDCASE.
ENDLOOP.
read table special_data into ls_special_data

with key fieldname = 'EST_COSTS'.
if sy-subrc eq 0.
* calculate estimated costs dependent on MONITOR

ls_total = 100.
if ls_monitor eq 'X'.
ls_total = ls_total + 350.
endif.
* write estimated costs into special field EST_COSTS

write ls_total to ls_special_data-fieldvalue LEFT-JUSTIFIED .
modify special_data from ls_special_data index sy-tabix.
endif.
endcase.
 Input help (Set Additional Data method):
To create input help for a characteristic (such as AIRPORT) in the BAdI, you need to
create two additional internal tables for the texts to be provided (such as
AIRPORT_OPTION_LABEL) and the value to be transferred (such as
AIRPORT_OPTION). On the HTML template, the input help is displayed using a
dropdown list box (section 4.3). For a complete example, see the BAdI implementation
for the standard scenario SH01 Shuttle to Airport.

 To make the effectiveness of a BAdI method depend on the mode:
* only for CREATE mode

check mode = 'CREATE'.
 Reading and setting the special request fields in the BAdI methods:
It is easy to access the general request data in the BAdI implementations because this data
is transferred to the methods as a GENERAL_DATA structure. The special request data
defined as characteristics in ISR Customizing, on the other hand, is listed in a table. The
SPECIAL_DATA table contains a row for each characteristic. Therefore, it is normally
necessary to transfer this tabular data into corresponding application structures at the start
of a BAdI method, and then write it back to the table at the end of the method. Two
function modules are available for this purpose:
ISR_SPECIAL_DATA_TO_STRUC
Moves the special request data from the SPECIAL_DATA table to a structure. The
request data that has the same name as a field name in the structure is transferred from the
table to the structure.
ISR_STRUC_TO_SPECIAL_DATA
Same as ISR_SPECIAL_DATA_TO_STRUC but in the reverse direction.
Example 1: Structure with reference to the DDIC
* Stammdaten Innenauftrag:
DATA: ls_master_data TYPE bapi2075_7.
* spezielle Antragsdaten in Struktur füllen

CALL FUNCTION ‘ISR_SPECIAL_DATA_TO_STRUC’
EXPORTING
it_special_data = special_data
CHANGING
cs_data = ls_master_data.
* weitere Verarbeitungsschritte
*…
* Zurückfüllen der speziellen Antragsdaten

CALL FUNCTION 'ISR_STRUC_TO_SPECIAL_DATA’
EXPORTING
is_data = ls_master_data
CHANGING
ct_special_data = special_data.
Example 2: Local structure
* Stammdaten Innenauftrag:
DATA: BEGIN OF mydata,
order TYPE aufnr,
description(40) TYPE c,

END OF mydata.
* spezielle Antragsdaten in Struktur füllen

CALL FUNCTION ‘ISR_SPECIAL_DATA_TO_STRUC’
EXPORTING
it_special_data = special_data
CHANGING
cs_data = mydata.
* weitere Verarbeitungsschritte
*…
* Zurückfüllen der speziellen Antragsdaten

CALL FUNCTION 'ISR_STRUC_TO_SPECIAL_DATA’
EXPORTING
is_data = mydata
CHANGING
ct_special_data = special_data.
You can use the same function modules for reading and setting the ADDITIONAL_DATA
table.
5. Request Form as Java iView in Enterprise Portal 5.0
1.24 Generating and Installing a Java iView for the ISR
As an alternative to the request form as an Internet service (ITS technology) described in

chapter 4, you can also implement the request form using a Java iView in the Enterprise
Portal 5.0. The entire back-end logic in R/3 remains intact in this case, meaning that you do
not have to make any changes to Customizing for your characteristics, tasks, or activities. (It
would even be conceivable to run a scenario using an Internet service and use it as a Java
iView at the same time.)
To design forms for your portal, you only need to create two Java Server Pages (JSPs). The
following section explains the syntax, structure, and layout of the JSPs.
Unfortunately, it is currently not possible to have a Java iView generated. Therefore you need
to copy an existing Java iView, modify it, and install it in your Portal. This process is
described in more detail below.
You can only assign one Java iView (which determines the layout of the request form) to each
ISR scenario. The Java iView for an ISR request form has the following files that are stored in
a PAR file:

The *.par file has two JSP pages that determine the layout of the request form (IsrMain.jsp)
and the confirmation page (IsrConfirmation.jsp) (success message once the request has been
submitted). The default.properties file contains the reference to a generic Java service
(com.sap.pct.fin.isrprocessevent) that implements the generic flow logic of an ISR request
form. This generic Java service must not be changed.
The original *.jar file or the Manifest.mf file is not needed.
To create a new Java iView (such as ISR_TEST) for a certain R/3 scenario (such as TEST):
1. Copy one of the supplied .par files (such as com.sap.pct.fin.isr_sor1mpo.par) and rename
the new .par file (such as isr_test.par).
2. Extract isr_test.par to the local C:\ directory on your computer using WinZip or a similar
program.
Set the Use folder name indicator when you do the extraction.
3. In default.properties (under C:\profiles\...), maintain the scenario key defined in R/3 (such
as IsrScenario=TEST) and the name of the logical system (such as
SystemIdentifier.value=SAP_R3_Financials).
Example:

4. The new isr_test.par file contains two JSPs. These are:
 Request form (C:\pagelet\IsrMain.jsp)
 Confirmation page (C:\pagelet\IsrConfirmation.jsp)
If you use Business Package MSS 50.1, the names of these two files must not be changed.
The main task is now to modify the request form IsrMain.jsp or the confirmation page
IsrConfirmation.jsp (see the following section).
If you use Business Package MSS 50.2, you can use your own JSP for IsrMain.jsp with a
name you assign (such as MyOwnMain.jsp) instead of IsrMain. Enter the name of your
JSP in default.properties as the value of parameter Isr_NewMainJsp (see under 2.).
In this case you create the JSP in the folder C:\pagelet\ (such as MyOwnMain.jsp). You
must then insert the JSP into the *.par file (such as isr_test.par) as described below. If you
use your own JSP, do not delete IsrMain.jsp. You cannot replace IsrConfirmation.jsp with
your own JSP.
Once you have set up the request form, add the data you changed in steps 3 and 4 using
Add to Zip from the WinZip program to the .par file copied in step 1 (such as isr_test.par)
using the following WinZip settings:

Make sure that the paths of the files in the copied *.par files match the paths in the
original *.par file. This should, however, be achieved by selecting Save extra folder info.
5. Enter the name of the new Java iView in extended ISR Customizing (view:
V_SCENARIOXMPO or with transactions QISRSCENARIO (since MSS 50.2) or
SIMG_SPORT (MSS 50.1)) as the portal component (such as isr_test.default). Use upper
and lower cases as appropriate.
6. Load the new Java iView with the iView PDKContentAdmin.ArchiveUploader in
Enterprise Portal 5.0.
Caution: Make sure that the menu paths in the .par file are not lost when you process the
files.
1.25 Layout Options
The ISR framework is designed to ensure as much freedom as possible when creating request
forms, and at the same time to include as many standard requests as possible. You therefore
create your own JSP (IsrMain.jsp) for each ISR scenario, which you can modify as needed.
The layout options are described below, starting with the most basic.
Note that in the Web browser the form is stateless. This means there is only a connection
between the server and R/3 when you access the form again, or when the form is processed
for example by choosing a pushbutton and the flow logic of the form is processed. This

ensures the best possible performance when many users are using the ISR framework at the
same time. For this reason it is necessary to store some form-specific and scenario-specific
parameter values in the browser temporarily. This is achieved with the hidden input fields.
Example:
<input type="hidden" id="SCENARIO" name="SCENARIO"

value='<%= ISR.getScenario() %>'>
These lines should therefore not be missing or modified in any JSP.
IsrMain.jsp must always have the following structure. Copying and modifying an existing
scenario assures that the JSP contains all necessary directives.
<%@taglib uri="htmlbtld" prefix="hbj" %>

<%@ page session="true" %>
<jsp:useBean id="ISR" scope="request" class="com.sap.pct.fin.util.isrprocessevent.IsrBean" />
<jsp:useBean id="ISRBundle" scope="page" class="com.sap.pct.fin.util.isrprocessevent.IsrBundle" />
<%-- Main ISR page to display the service request form in all modes (CREATE; DISPLAY; CHANGE) --%>
<hbj:content id="myContext" >

<hbj:page title="Service Request: Name Of The Request">
<jsp:setProperty name="ISRBundle"
property="pageContext"
value="<%= myContext %>"
/>
<hbj:form id = "myForm">
<%-- Hidden input fields for statelessness --%>

<input type="hidden" id="SCENARIO" name="SCENARIO"
value='<%= ISR.getScenario() %>'>
<input type="hidden" id="MODE" name="MODE" value='<%= ISR.getMode() %>'>
<input type="hidden" id="REQUEST_NO" name="REQUEST_NO"
value='<%= ISR.getNotif_no() %>'>
<input type="hidden" id="ISR_FORM_VIEW" name="ISR_FORM_VIEW"
value='<%= ISR.getIsr_form_view() %>'>
<input type="hidden" id="ISR_PAGE" name="ISR_PAGE"
value='<%= ISR.getIsr_page() %>'>
<input type="hidden" id="WF_CALLBACK_URL" name="WF_CALLBACK_URL"
value='<%= ISR.getWfCallbackUrl() %>'>
---------------- Insert your request fields or other HTML here ---------------------
</hbj:form>
</hbj:page>
</hbj:content>
1.25.1 Images
You can add graphics as GIF files.

To add a .gif file to your .par file (such as isr_test.par), use the Add to Zip function in WinZip.
Make sure that the path of your .gif file in the .par file matches the path images\... of the
existing file error.gif.
You insert your file into the JSP as shown below. The .gif file in this example has the name
TRAFFIC_LIGHT_RED.GIF. The ID parameter can be filled as needed (such as
ownpicture):
<hbj:image id="ownpicture"
src='<%= componentRequest.getResource(componentRequest.getComponentContext().
getComponentName(), "image", "images/" +
"TRAFFIC_LIGHT_RED.GIF").
getResourceInformation().getURL(componentRequest) %>' alt="E" />
1.25.2 Access to Form Data
You access the form data that was initialized and tested in R/3 by using a generic Java bean.
You can access the value, the label (short, medium, long), the output length, and the ready-
for-input status of all the characteristics defined in the scenario. The following methods are
available (such as for the NEW_USER characteristic):
<%= ISR.getValue("NEW_USER") %>
<%= ISR.getLabelK("NEW_USER") %>
<%= ISR.getLabelM("NEW_USER") %>
<%= ISR.getLabelL("NEW_USER") %>
<%= ISR.getSize("NEW_USER") %>
<%= ISR.getDisabled("NEW_USER") %>
1.25.3 Layout and HTMLB
Enterprise Portal 5.0 enables flexible yet uniform creation of the portal layout using
standardized CSS style sheets. These can be adapted to the branding of your company by the
portal administrator. The end user can select the layout for their portal from a standard
selection of layout themes. A prerequisite of a standard layout for the central CSS style sheets
is that the Java iViews use HTML business controls (HTMLB). HTMLB also enables
effective, time-saving programming of form elements, and is thus used for the ISR as well.
The HTMLB taglib directive is defined at the beginning of IsrMain.jsp and IsrConfirmation:
<%@taglib uri="htmlbtld" prefix="hbj" %>
1.25.4 Different Layouts for Different Request Modes (Create/Change/Display)
You can create different layouts for the different request modes using the ISR_MODE
parameter in the JSP. Depending on the mode, this parameter has the value CREATE,
CHANGE, or DISPLAY. You could therefore add a pushbutton such as Send in the Create
mode as follows:
<% if (ISR.getValue("ISR_MODE").equals("CREATE") == true) { %>

<hbj:button id="SEND"
text="Send"
tooltip=”Send request”
onClick="submit"
design="emphasized"
/>
<% } %>

1.25.5 Layout Based On User Role
It is often the case that the processor needs to have more request fields than the users who
enter the requests. The parameter ISR_FORM_VIEW is provided in the JSP for this purpose.
This has the default value ISR REQUEST. When the processor calls up the request form, it
has the value ISR_PROCESS (or ISR_APPROVE for the person approving). You can display
an extra field for the processor as follows:
<% if (ISR.getValue("ISR_FORM_VIEW").equals("ISR_PROCESS") == true) { %>

text="Send"
tooltip=”Send request”
onClick="submit"
design="emphasized"
/>
<% } %>
To control the layout in more detail, you can also set the parameter ISR_FORM_VIEW from
within the BAdI methods (see section 4) using rules that you define.
1.25.6 Page Layout and Scrolling Logic
You can use the ISR framework to define request forms with multiple pages for a more
structured entry of data (if necessary, you can display the entries made on the previous pages
on the final page). The parameter ISR_PAGE is provided for this purpose in the JSP. You can
scroll backwards or forwards using buttons that trigger one of two ISR standard commands:
 NEXT_PAGE: One page forward
 PREV_PAGE: One page back
<hbj:button id="PREV_PAGE"
text="<- previous page"
tooltip="previous page"
onClick="submit"
design="emphasized"
/>
<hbj:button id="NEXT_PAGE"
text="next page ->"
tooltip="next page"
onClick="submit"
design="emphasized"
/>
When one of these commands is triggered, the number of the current page (parameter
ISR_PAGE) is automatically incremented or decremented by one. If a more complex
scrolling logic is required (for example, depending on the entries made on the page), you can
explicitly set the value of the parameter ISR_PAGE in the BAdI methods.

1.25.7 Multiple Languages
The request fields that you defined as characteristics have descriptions that come from the
request fields from R/3. This means that the descriptions are available in all required
languages.
In addition, standard texts are provided for long texts, error output, and buttons by means of
the resource bundle ISRBundle in the JSP. This means that you can display the header for the
long text as follows:
<hbj:textView text="<%= ISRBundle.getLocalString(\"oldcomment\") %>" design="LABEL"/>
You can also define your own resource bundles with the standard techniques and use them in
the JSP.
1.25.8 Layout Based On Values of Individual Fields
You can display fields depending on the values of individual characteristics (such as
ORDER):
<% if (ISR.getValue("ORDER").equals("403567") == true) { %>

<hbj:inputField id="NEW_USER"
type="String"
visible="true"
disabled='<%= ISR.getDisabled("NEW_USER") %>'
value='<%= ISR.getValue("NEW_USER") %>'
size='<%= ISR.getSize("NEW_USER") %>'
/>
<% } %>
1.26 Elements of the Request Form
 Input field (one row) for the characteristic COLOR:

<hbj:inputField id="COLOR"
type="String"
visible="true"
disabled='<%= ISR.getDisabled("COLOR") %>'
value='<%= ISR.getValue("COLOR") %>'
size='<%= ISR.getSize("COLOR") %>'
/>

You can generate the value list for the dropdown list box (such as COLOR OPTION and
COLOR OPTION LABEL) in the BAdI Method
SCENARIO_SET_ADDITIONAL_VALUES. (In the example shown, selecting an entry
from the input help triggers the optional event onSelect = "check", which leads to an R/3 call.
This could be used to display the values of other input help domains in the R/3 BAdI, for
example.)
<hbj:dropdownListBox id="COLOR"
tooltip="Tooltip for COLOR"
onSelect = "check"

>
<% for (int i = 1; i <= ISR.getAdditionalDataLength("COLOR_OPTION"); i++) { %>
<hbj:listBoxItem key='<%= ISR.getAdditionalData("COLOR_OPTION",i) %>'
value='<%= ISR.getAdditionalData("COLOR_OPTION_LABEL",i) %>'
selected='<%= ISR.getSelected("COLOR","COLOR_OPTION",i) %>'
/>
<% } %>
</hbj:dropdownListBox>
 Checkbox for the characteristic COLOR:
<hbj:checkbox key="COLOR"
id="ID1"
text="Checkbox Color"
tooltip="Click the checkbox"
checked='<%= ISR.getChecked("COLOR") %>'
encode="false"
/>
<hbj:radioButtonGroup id="COLOR" columnCount="2"

selection='<%= ISR.getValue("COLOR") %>'>
<hbj:radioButton id="R1"
key="red"
text="Choice: red"
tooltip="Chose red"
encode="false"
/>
<hbj:radioButton id="R2"
key="blue"
text="Choice: blue"
disabled='<%= ISR.getDisabled("RADIO") %>'
/>
</hbj:radioButtonGroup>
 Text field (multiple rows) for the characteristic MYTEXT:
<hbj:textEdit id="MYTEXT"
text='<%= ISR.getTextAreaContent("MYTEXT") %>'
cols="80"
rows="5"
/>
 Predefined standard text fields ISR_NEW_LONG_TEXT and ISR_LONG_TEXT

request, the person approving it, or the person processing it, the comment is added to the
notification long text. You can also insert an automatic log row with the date, time, and
user in notification customizing in the SAP reference IMG under Cross-Application
Components  Internet/Intranet Services  Internal Service Request  Scenario
Definition  Prepare General Notification  Notification Processing  Overview of
Notification Type Format Long Text. New comments are entered in the text field
ISR_NEW_LONG_TEXT, while old ones are displayed in ISR_LONG_TEXT:
<hbj:textEdit id="ISR_LONG_TEXT"
text='<%= ISR.getTextAreaContent("ISR_LONG_TEXT") %>'

cols="80"
rows="5">
<%
ISR_LONG_TEXT.setDisabled(true);
%>
</hbj:textEdit>
<hbj:textEdit id="ISR_NEW_LONG_TEXT"
text='<%= ISR.getTextAreaContent("ISR_NEW_LONG_TEXT") %>'
cols="80"
rows="5"
/>
 Buttons
<hbj:button id="CHECK"
text="Check"
tooltip="Submit ISR-Form"
onClick="submit"
design="emphasized"
/>
text="Send/Save"
tooltip="Submit ISR-Form"
onClick="submit"
design="emphasized"
/>
You can create the button for a freely definable user command (which can be evaluated in
the BAdIs) by defining the ID of the button accordingly. The ID is available as a user
command in the R/3 BAdIs.
 Date field
Prerequisite: Business Package MSS 50.2 and the correction in OSS Note 552175 in your
plug-in system.
You can also use the date field together with HTMLB input help. To do this, assign the
value true to the parameter showhelp.
Entry field for characteristic DATE:

<hbj:inputField id="DATE"
type="Date"
showhelp=”true”
visible="true"
disabled='<%= ISR.getDisabled("DATE") %>'
value='<%= ISR.getValue("DATE") %>'
size='<%= ISR.getSize("DATE") %>'
/>
 Positioning
HTMLB and the grid layouts enable relative positioning. However, you can also position
with all of the other HTML methods, such as:
<table border="0" align="center" width="98%"><tr><td>
…
</td></tr></table>

HTML methods are sometimes advantageous when you want to improve the performance
of the form.
<hbj:gridLayout>
<hbj:gridLayoutCell rowIndex="1" columnIndex="1">
<hbj:textView text="NOTIF_NO_OUT" design="LABEL"/>
</hbj:gridLayoutCell>
<hbj:textView text='<%= ISR.getValue("NOTIF_NO_OUT") %>'/>
<hbj:textView text="RETURN-MESSAGE" design="LABEL"/>
<hbj:textView text='<%= ISR.getValue("RETURN-MESSAGE") %>'/>
</hbj:gridLayout>
1.27 Initialization, Input Help, Verification, User Commands
1.27.1 Initialization Through Parameterized URL Call
The fields on the request form can be initialized by means of a parameterized URL call. The
syntax for initializing the COLOR characteristic with RED and the TASTE characteristic with
GOOD is shown in the following example:
…. isr_test.default?SCENARIO_PARAMS=COLOR=RED$TASTE=GOOD
1.27.2 Initialization, Input Help, and Verification for Clients in HTML Template
You can define any initializations, input help, and verifications directly in the JSP. Modify the
JSPs accordingly. If you use the normal JavaScript methods, the verifications will only take
place in the clients, which improves performance. If you use Java as the script language,
processing is on the Web server. All R/3 data (such as validation tables) is available for
initializations and input help in the R/3 BAdIs.
1.27.3 Programming BAdIs
The R/3 logic with Java iViews is basically the same as that with Internet Services (ITS). See
section 4.4.3.
6. Request Form as Adobe Form

You enter the request using an Adobe form in PDF format specially designed for the scenario.
A form must be assigned to the scenario for this purpose. A form can be assigned to more
than one scenario, but the characteristics of the different scenarios must be the same.
You can assign an existing Adobe form to the ISR scenario or generate a new form.

6.1 Generating an Adobe Form
You can enter a name for the form in the form field. The form generation process creates a
form with that technical name. If you leave the form field empty, the system generates a form
with the name Z_ISR_FORM_<scenario> (such as Z_ISR_FORM_Z123 for scenario Z123).
To create a new Adobe form for your ISR scenario, choose Generate. A dialog box appears
with three options:
 Without Template:
An new empty Adobe form is created. The characteristics of the scenario are transferred to
the data part of the form and are available on the body page of the form layout for data
binding of the fields and form elements to be defined. However, the layout (body page) is
empty. You must manually modify the layout using the screen elements of the Library
(right side) by dragging and dropping them.
 With Template (from Scenario):

An existing Adobe form is copied. In addition to the characteristics of the new scenario,
the characteristic of the template scenario are transferred to the data view data container of
the new form and the new interface.
 Generate Form (SAP Design):

A new Adobe form is created based on the template ISR_FORM_SCENARIO. This form
has the SAP standard design used in all standard scenarios. The form contains various
graphical elements that you can use as a template for custom fields and elements on the
form. You can also use the ISR Controls library. For information about how to obtain this
library, see Note 741381. (It is planned to ship the ISR Library with the SAP GUI in the
future.)
With the form generated thus far you access the Form Builder (see figure below), which you
can also access directly with transaction SFP. The Adobe form is a client-independent
workbench object. This means that to generate a new form, you need a customer package to
which the workbench object form is assigned. For this you need a transport request to be able
to transport the form to other systems. Instead of transporting the form, however, you can also
create it as a local object.
You can now make changes to the form in the Form Builder (for explanations, see below).
When you are finished, you must save and activate the form.

6.2 General Characteristics
In addition to the special characteristics from the scenario, the form has the general fields
ISR_LONG_TEXT and ISR_NEW_LONG_TEXT or the field groups GENERAL_DATA
and CONTROL_DATA in a structure.
 The fields ISR_NEW_LONG_TEXT_NEW or ISR_LONG_TEXT are the standard
fields for entering comments as body text or for displaying the comments of service
requests that have been submitted.
 The structure GENERAL_DATA contains the address data of the roles, such as the
applicant (CREATED_BY-…), the approver (APPROVED_BY-…) and the processor
(PROCESSOR-…), as well as general data (HEADER-… ;such as scenario,
notification number, price list, etc.). In the form, these fields can be displayed,
changed, or entered. They can also be used in the BAdIs for evaluation purposes.
 The structure CONTROL_PARAM is only for influencing the layout of the screen
elements at runtime. Using the script language of the Form Builder and the content of
CONTROL_PARAM of the Form Builder, any field can be set to visible/not visible,
ready for input/not ready for input, etc. For detailed explanations on the use of the
Form Builder script language in R/3, see the documentation (section 6.7). For
examples regarding the use of the script language, see the screen elements of the ISR
Library (see below) or of the forms shipped by SAP. The structure
CONTROL_PARAM contains the following fields:

 ISR_MODE (= CREATE, CHANGE, DISPLAY) – indicates the mode of the form
 ISR_REQUEST_NO – contains the notification number (if available)
 ISR_EVENT – contains the last event fired. This parameter must be used for
customer-defined events on pushbuttons. When the pushbutton is executed, event
CHECK_DATE fires. This event can be evaluated in the corresponding BAdI (see
section 4.4.3).
Example for pushbutton script with event:
----- data.#subform[0].Button::mouseDown - (FormCalc, client)

--------------------------------------
//Set ISR_EVENT for BAdI processing in backend

$record.CONTROL_PARAM.ISR_EVENT = "CHECK_DATE"
----- data.#subform[0].Button::click - (JavaScript, client)

----------------------------------------
//Trigger call to backend for BAdI user command processing

app.eval("event.target.SAPSubmit();");
 ISR_FORM_VIEW (= ISR_REQUEST, ISR_APPROVE, ISR_PROCESS) –

contains the current ISR role (applicant, approver, processor) of the user that just
accessed the form.
 ISR_PAGE – contains the page of the form (default value 1)
 ISR_REVIEW – has the value X as soon as the perspective Review and Submit
appears (this perspective is only provided to the applicant).
 ISR_CONFIRMATION – has the value X as soon as the perspective Confirmation
appears (this perspective is only available in the CREATE and CHANGE modes).
Example for a script (FormCalc) of an input field:
----- data.#subform[0].TextField1[1]::ready:form - (FormCalc, client)

------------------------------
//Check ISR control parameters for read/write access

if($record.CONTROL_PARAM.ISR_REVIEW == "true" |
$record.CONTROL_PARAM.ISR_MODE == "DISPLAY" |
$record.CONTROL_PARAM.ISR_FORM_VIEW =="ISR_APPROVE" )
then
this.access = "readOnly"
endif
The field is not ready for input

o when the form is displayed in the perspective Review and Submit
o when the form is accessed in display mode
o for the approver role

6.3 Automatic Generation of New Characteristics
 When you save and exit the Form Builder, a dialog box appears in which you can have
the system generate new characteristics in ISR basic customizing.
 The pushbutton Import Form Fields next to the form field adds new characteristics
based on the form opposite.
If you have added new form elements in the Form Builder for which there is no linkage to a
characteristic in the Data View (that is, there is no data binding between the form element and
a characteristic), a characteristic is generated with the same technical name as the form
element (specified in the Form Builder for the form element under Object Binding in the
Name field). The name of the characteristic is taken from the description entered directly on
the form element. The data binding with the form element is then added to the form
automatically.
Notes:
 If more than one form element has the same technical name, the characteristic is only
created once.
 The generated characteristics are normally untyped. Exception: form fields of the type
Date are generated with the DDIC reference field SYDATUM.
 When new characteristics are generated, existing characteristics are not changed.
 If new characteristics are added manually in ISR Customizing, they can be transferred
with the Change pushbutton in the Data View context of the form (dialog box).
6.4 Definition of New Screen Elements on the Form
On the right side of the screen in the Library, choose a screen element (such as Text Edit)
from a tab (such as Standard) and select it. Then drag it to the body page. You can then
modify the attributes of the element (size, position, description, field type, etc.). You can then
manually link the new screen element to an existing characteristic from ISR Customizing, or
have the system generate a characteristic automatically.
6.5 Assignment of Form Fields to Characteristics from ISR Customizing (Data

Binding)
The assignment can be made in different ways:

 When you generate or change a form, the characteristics are already defined and can
be accessed in the Data View:
In the Data View, choose the desired characteristic and open it down to the subelement
FIELD. Select FIELD and drag it to the screen element.
You can also select the linkage to the characteristic in the Default Binding attribute of
the screen element on the Object  Binding tab.
The data binding has the form: $record.<characteristic name>[*].FIELD
Repeat the whole procedure for the other characteristics.

Note:
In the supplied forms, the data binding may have the value $data.data.<characteristic
name>[*].FIELD instead of $record.<characteristic name>[*].FIELD.
The version with "data.data" is obsolete and should no longer be used in new forms.
However, the obsolete version still functions correctly.
 When characteristics are generated automatically based on new form elements, the
data binding to the form elements is generated as well (see section 6.3).
6.6 Testing
Before you can test the Adobe form with the test function (test symbol next to the form), the
portal server must be specified in R/3 Customizing. To do this, go to Additional Data for
Scenario and choose Server. In the table, select Adobe Server and enter the URL for the
server (such as HTTP://<your
server>/WEBDYNPRO/DISPATCHER/SAP.COM/PCUI_GP~ISR/). Replace <your server>
with the name of your server and the port. Example: PGWDF123.WDF.SAP.CORP:40000.
This server setting applies to all scenarios in that system and client.
6.7 Additional Documentation
For more information on defining Adobe forms, see the documentation for the Form Builder
in the SAP Library under SAP NetWeaver Application Platform (SAP Web Application
Server)  Business Services  PDF-Based Forms.
If you want to enter forms in SAP design, see the Design Guidelines for Adobe forms in SAP
design, available in the SAP Service Marketplace under service.sap.com/isr. For such forms,
SAP provides a collection of predefined screen elements as an additional Library (ISR
Library), which you can use in the Form Builder. Note 741381 describes how to obtain this
ISR Library and add it to the Form Builder.
6.8 Standard and Custom Scenarios with Adobe Forms in the SAP Enterprise
Portal
The Adobe forms are technically part of the Web Dynpro application IsrForm in the
Development Component (DC) ISR from the Software Component PCUI_GP.
If you want to use custom scenarios with Adobe forms in your Enterprise Portal, you need to
define an iView based on the Web Dynpro application IsrForm and add it to your portal. You
can optionally use the general iView IsrAdobeForm (com.sap.pct.isradobeform) with the PCD
parameters scenario and mode. This iView is delivered with mySAP ERP 2004 SP2. You can
also use it as a template for custom iViews.
Scenarios Provided
The Web Dynpro application IsrForm consists of a "road map" with three steps (1: Data
entry, 2: Check and submit, 3: Confirmation) along with the Adobe form and pushbuttons for
navigating between the steps (see figure below).

All supplied scenarios of the ISR are integrated in other Web Dynpro applications, so access
to them is context-sensitive.
Two solutions are available:
 Direct integration in the road map of other Web Dynpro applications
Example: Personnel Change Request (PCR) in the Business Package MSS
 Indirect integration through a scenario group
Scenario groups are used for context-based access to one or more scenarios by means
of an application toolbar. You control which scenarios are available in the application
toolbar in Customizing under Cross-Application Components Internet/Intranet
Services Internal Service Request Scenario Definition Define Scenario Groups.
You can also replace the standard scenarios with your own custom scenarios.
You can program a check routine for each scenario that verifies whether the context in which
the scenario is accessed is correct. If the context is not correct, you can have an error message
issued that prevents the ISR form from being accessed. To do this, use BAdI QISR6 with
method SCENARIO_CHECK.
Note: These ISR forms must use context-sensitive access (example: Equipment Monitor).
Context-sensitive means that when an ISR form is accessed from a monitor, data on the object
selected in the monitor is transferred to the internal service request. It must be possible to
process this data in your form. For more information, refer to the documentation on the
supplied scenarios.

7. Processor Determination and Workflow
1.28 Processing Notifications in a Worklist
You can set up notification processing with or without a workflow. If no workflow is used,
notifications and tasks are processed in a worklist under Office  Notification  Worklist 
Notifications/Tasks (transaction IQS8/IQS9). Processors access notifications and tasks using
selection criteria they define themselves. No further Customizing settings are required to
enable use of the worklist. When an internal service request is submitted, the processor is
saved in the notification and cannot be changed. The processor can select the notification in
the worklist accordingly.
Note: Standard roles are resolved at the time you create the notification. The processor is
stored in the notification at this point and cannot be changed later. This means that if the
responsibility changes in the standard role (for example, the person responsible moves to
another department), it is not possible to update this change in the notification.
1.29 Processing Notifications in the Workflow
If you use a workflow, notifications to be processed/approved are sent to the workflow inbox
of the person responsible, who can access the notifications by double-clicking on them. He or
she can forward the notification to other processors and use all other functions of the
workflow. In the following, it is assumed you are using an ISR with the notification type
General Notification. Otherwise other workflow settings may be relevant.
The object types below are to be processed using the workflow:

 BUS7051 - General Notifications
 QMSM - Notification Task (general, independent of the notification type)
For General Notifications, both of the following standard workflow templates are relevant:
 3100019 - Workflow template for notification processing

This workflow template is always started when a general notification is created (event
CREATED) or processed again (event INPROCESSAGAIN).
 20001028 - Workflow template for task processing
This template is started when a task is created (event CREATED).
You configure the workflow as follows:
Activate the Workflow for General Notifications
First you activate the workflow for General Notifications. You do this in Customizing under
Cross-Application Components  Internet/Intranet Services  Internal Service Request 
Scenario Definition  Prepare General Notification  Notification Processing  Activate
Workflow Template and Assign Processor.
Under Activate event linking, activate the two workflow templates described above for the
three named events:

Assign Processors to Standard Tasks in the Workflow
The workflow template for notification processing (3100019) contains four standard
workflow tasks, which are generally executed in the following sequence:
 Approve Notification (20000906)

The system checks whether a new notification requires approval. If so, this standard
task is sent to the relevant person for approval.
 Process New Notifications or Notifications Back in Processing (20000889)

When a new notification is created or a notification is back in processing and no open
tasks exist, the standard workflow task is sent to the processor if approval was granted
or no approval is needed.
 Process Notification (20000890)

If a new notification is created or a notification is back in processing and open tasks
exist, the standard workflow task is sent to the processor if approval was granted or no
approval is needed.
 Complete Processing (20000887)

If no open tasks exist, this standard workflow task is sent to the processor. Once all
tasks are completed, the processor must either close processing or initiate new tasks.
The processor of this last task thus acts as a coordinator.
Note: This task cannot be completed automatically by default. It is not possible to

close the notification automatically after completion of all tasks. If you want to avoid
manual processing, see whether your scenario can be structured without using tasks.
The processor/approver is selected based on two criteria that must both be fulfilled:
 This person is assigned as the processor in workflow customizing for the standard task.
 In notification customizing, this person must be entered in the partner function person
responsible or approver (section 5.4.1 Processor Determination in Notifications and
Tasks describes this in detail).
This means that a user entered in the notification as the responsible person or the approver
will not receive a workflow task unless he is assigned to that task in workflow customizing.
Instead, the workflow task is sent to all other users assigned to that task in Customizing. The
same thing happens if no person responsible/approver is entered in the notification.
When distributing the tasks, the workflow always compares the list of possible receivers with
the users entered in the notification. This takes place using standard roles 20000116
(approval) and 20000101 (residual tasks) entered in the standard workflow tasks – please do
not modify these standard roles.
The workflow template for notification processing (20001028) contains a standard workflow
task:

Complete Task (20000886)
Sent to the task processor when the task is created.
Assignment of the processor to the standard workflow tasks takes place in Customizing under
Scenario Definition  Prepare General Notification  Notification Processing  Activate
Workflow Template and Assign Processor  Assign Agents.
1.30 Partner Functions and Partner Determination Procedures
Notification processing can involve various people with different functions. The predefined
functions for ISR are:
 AB = Responsible Department
Organizational unit responsible for processing the request
 AO = Author
User who submitted the request
 KU = Coordinator
User who processes the notification, or coordinates its processing
 §A = ISR Contact Person
User who built the ISR scenario or is responsible for it.
 §G = Approver
User who approves the notification
 §P = Task Processor
User who processes the task
These partner functions are defined in partner definition procedure SR00, which is assigned to
the ISR notification types (notification types 1 – 9, 50 – 79). Partner functions define only one
name for a role and the relevant partner type (user, organizational unit).
If you require other partner functions for your ISR scenarios, you can define your own partner
determination procedure (list of possible partner functions) and assign it to the corresponding
notification type. See Customizing under Cross-Application Components  Internet/Intranet
Services  Internal Service Request  Scenario Definition  Prepare General Notification
 Notification Creation  Partner  Define Partner Determination Procedures.

In the Customizing activity Define Partner Determination Procedures, choose General
Notification. Create a new partner determination procedure and enter the desired partner
functions with the corresponding partner types. For more information on partner
determination procedures, partner functions, and partner types, refer to the documentation for
the Customizing activity.
1.31 Processor Determination from the Standard Role in the Workflow
1.31.1 Processor Determination for Notifications and Tasks
Regardless of whether you use the worklist or the workflow, you can find the processor of a
notification or task using the standard function from the workflow.
With notifications, you maintain the standard role in Customizing for notification types under
Scenario Definition  Prepare General Notification  Notification Creation  Partner 
Define Partner Determination Procedures  Assign Partner Functions to Notification Type.
Select a notification type and double-click the entry Assign Partner Functions to Notification
Type.
Under Partner Functions for Notification Processing in the Person Responsible field, select a
partner function defined in your partner determination procedure (normally Coordinator).
Enter the desired standard workflow in the next field.

To define the approver, select the Approval required indicator at the bottom of the screen and
enter Approver as the partner function in the Partner Function for Approver field. Enter a
suitable standard workflow role in the next field.
You can use the pushbuttons to go to the maintenance screen for workflow standard roles (see
next section). If you have not created a standard role, you can define it using transaction
PFAC.
For tasks, you can enter a fixed processor or a standard role with flexible processor
determination directly in ISR Customizing (entry Tasks) for the corresponding task. (ISR
Customizing then takes priority over the standard roles for task processing that are maintained
directly in the notification.)
1.31.2 Customizing Standard Roles for the Workflow
The standard role for the workflow enables flexible processor determination. The processor
of the notification or task can be selected based on the scenario and the input values on the
request form (such as the cost center of the person entering the request).

Note that the standard role must return objects with partner types (such as User) from the
chosen partner function so that the object can be transferred to the notification. For example,
task processors (partner type User) must be users.
Use the Create symbol to go to the maintenance transaction (PFAC) for standard roles.
 In the Role definition, enter an abbreviation, a description, and the role type
Responsibilities (Note: The ISR framework supports only the role type
Responsibilities at the moment).
 In the description, you define information for this standard role. Note that this
standard role applies for all ISR scenarios of this notification type.
 In the Role Container, you refer to any characteristics that you defined specifically for
ISR scenarios (input fields on the request form), and/or to table fields from the
VIQMEL (notification-specific data) structure.
The role container should always include VIQMEL-AUSWIRK (scenario name) to

enable you to organize processor determination specifically for a scenario. Choose the
first '+' symbol (insert container element) and affirm the subsequent dialog box (with
reference to dictionary). Enter table VIQMEL, then ENTER. You see all the fields
from the table. Select the field AUSWIRK and confirm your entry. In the subsequent
dialog box, choose Create. Your container now contains the element Scenario.
To transfer the scenario characteristics that you defined to the container, click on the
first '+' symbol (insert container element) and do not affirm the subsequent dialog box
(no reference to dictionary). In the next dialog box, enter the element (characteristic
name) and a description.

 In the Responsibilities, you can define any responsibilities to which you want to assign
a processor. You can define criteria for every responsibility. (For example, you can
define the name of an IT system in the role contained. Every responsibility -
responsible system administrator - can be valid for a selected IT system name.) It is
not necessary to define all possible criteria (elements from the role container) for
responsibilities. Empty fields are not taken into account in role resolution. To create a
responsibility, choose Create responsibility. Confirm the subsequent dialog box and
enter the allowed values for the corresponding characteristic. Always enter a value for
the Scenario element to specify processor assignment for an ISR scenario. To assign a
user, choose the symbol Insert processor assignment. In the subsequent dialog box,
confirm User as the object type, confirm the validity period, and save the assignment.
Note: Before you assign the processor, you must define the corresponding
organization structures in transaction PPOME.
If the SAP standard partner functions and the associated partner types User and Department
are not sufficient, you can define advanced partner determination procedures for a notification
type to include suitable partner functions.

8. Costs and Integration with Controlling
It is possible to record costs in R/3 each time you submit or complete an internal service
request. Such costs can be:
 Administrative costs (such as the costs for the processor in the central department).
For this type of cost allocation, you can use the price list (see below) provided with
mySAP ERP2004.
 Follow-up costs generated by the business process triggered by the ISR (for example,
if the business process is ordering a material, the follow-up costs are the costs of the
material when purchased from a vendor). For this type of cost allocation, it is best to
use a template in Easy Cost Planning (see below).
Set the indicator “The scenario incurs costs”.
You must specify a controlling area.
Costs can be recorded in different ways:
 Estimated costs:
If you don't want to run a detailed cost calculation for the scenario, you enter the
estimated costs. The costs you enter are updated as the planned value on the specified
object.
 Template:

You use a template in Easy Cost Planning to update the actual costs to the object when
the notification is completed. The processor of the notification must manually perform an
activity to which function module QALK_ISR_AUTO_EXEC is assigned (example:
scenario SH01 Action box  function EX02 for scenario SH01). This function module
goes to the Execution Services transaction.
You can specify a template that determines the values for the cost allocation from the
information in the form. If you have not yet prepared a template, choose Create Template.
You then need to specify a costing variant and a fixed account assignment object.
If you have decided to use a template to record the costs, use the Easy Cost Planning
functions.
For more information on Easy Cost Planning, refer to the SAP Library under Financials
 Controlling  Product Cost Controlling  Product Cost Planning  Easy Cost
Planning and Execution Services.
 Price list:
The price list function simplifies ISR scenarios that involve administrative costs. The
administrative costs are calculated automatically based on the price list. The price list
contains all information needed to calculate the actual costs. A price list contains one or
more fixed prices.
Based on the predefined price (service type) selected, each request automatically updates
costs to a cost collector in Controlling (such as a cost center or order) once the notification
is completed. The processor does not have to update the costs manually.
Each entry in the price list corresponds to a service type (two-digit numerical value) that
includes the following information:
 Price (consisting of an activity price and a fixed quantity)
 Cost receiver
 Cost sender (sender cost center and activity type)
A service type is an activity that can be requested by an internal service request. In the
simplest case, an internal service request only offers one service type, for which the
Default indicator must be set. If more than one service type is possible, you use the
Default indicator to control which price is defaulted to the request form. The person
creating the request establishes the costs by selecting the appropriate service type. The
approver then sees the costs when they process the request. When the notification is
completed, the costs are allocated from the sender cost center to the cost collector.
The applicant can select a price on the form. To enable the applicant to select the service
type on the form, you define a field as a dropdown list box and assign to it the field
SERVICE_TYP from the general fields of GENERAL_DATA with data binding.
If you don't allow applicants to select the price manually in this way, the default service
type is used automatically.
For each service type, specify a cost center and activity type and assign an activity price,
quantity, and currency. When the notification is completed, the cost center is credited

with the costs (activity price times quantity) by means of internal activity allocation. The
account assignment object selected based on the strategy in the Costs block of ISR
Customizing is debited with the costs.
You can check a price list for consistency by entering the name of the scenario in the
Scenario field and choosing Check Price List.
Prerequisites
 The sender cost center exists.
 The activity type can be created while the price list is being edited. The following
settings must be made for the activity type under Variance values for actual
allocation:
Actual activity type category: 1 (Manual entry, manual allocation)
Actual price indicator: 7 (Manually determined for actual allocations)
Compared with the template, the price list is a relatively simple method of updating service
costs to Controlling. The template is recommended for complex costs allocations.
Cost collector
The costs calculated by one of the above methods are allocated to the account assignment
object defined in ISR Customizing under Strategy.
The following strategies are available:

 Fixed account assignment object
In this case you specify a cost center, internal order, or WBS element as the cost collector.
 Cost center of the initiator
The cost collector is the cost center specified in the applicant's user master.
 WBS element of the initiator
The cost collector is the WBS element specified in the applicant's user master.
 User exit
You specify the cost collector by implementing the BAdI QISR2 (method
ISR_ACCOUNT_ASSIGNMENT_GET) for your scenario.

9. Access to Request Forms: Integration of Request Forms in the
SAP Workplace or Existing Intranet or Internet Portals
Once you have set up new ISR scenarios, end users need to be able to find the request forms.
Since Web forms can be brought up simply by clicking on a link, many possibilities are
available for integration.
1.32 Integrating Request Forms in Existing Intranet Portals or External Portals
ISR scenarios can be accessed simply with a URL. This means you can easily add the ISR
scenarios to your company's existing intranet, extranet, or Internet pages. Most companies
already run self-service scenarios in their intranet, which can be enhanced by ISR scenarios.
You can add ISR services for customers to the company's external portal.
It would also be possible to send an e-mail with an ISR link to sales employees or customers
to inform them about new ISR services. You can create interactive ISR guides using a normal
word processing system simply by inserting links to ISR services at the relevant point in the
document. For example, you could write a guide for hiring new employees with links to
Booking Training Courses, Creating a System User, Ordering a PC and so on.
The syntax for calling a scenario with scenario key XXXX and the connected internet service
ZYYYY on ITS sap-ag.de:1080 is as follows:
http://sap-ag.de:1080/scripts/wgate/ZYYYY/!?~okCode=CREATE&scenario=XXXX
If you want, you can specify a default client and logon language by adding
&~client=800&~language=EN to the URL.
1.33 Integration in the SAP Workplace LaunchPad (Single Role Maintenance)
If you use the SAP Workplace, you can offer your employees a hierarchy of role-based ISR
services directly in the LaunchPad. The screenshot below shows how this could look.
The LaunchPad in the screenshot consists of a single role that contains folders with links to
the corresponding ISR scenarios. Start transaction PFCG in the workplace system. This
enables you to create single roles. Enter a new name for the single role (Z*) and choose
Create single role. Enter a description for the single role and choose Menu. Confirm the
subsequent dialog box and position the cursor on the Role menu folder.

Click on the Create folder symbol at the top left. Enter a name for the folder. To create an
ISR link, click on Insert other object. In the dialog box that appears, choose the URL radio
button (default), and in the next dialog box enter a description that appears in the LaunchPad
and the link to the ISR service (see the previous section on the syntax of URL). You can
rearrange the entries and folders by dragging them to new locations. On the User tab, you can
now assign the new single role. Test the new LaunchPad menu in the Workplace.
1.34 ISR Start Page
The Workplace provides a generic start page for the ISR (Internet service QISR). This start
page is no longer needed now that SAP Enterprise Portal 5.0 is available.
1.35 ISR in SAP Enterprise Portal 5.0
SAP Enterprise Portal 5.0 provides you with a flexible means of designing the portal pages
and their navigational structure. You can use the detailed navigation to place ISR scenarios on
portal pages where appropriate. The user can then access the appropriate request forms
directly without having to exit their work context. In the example below of the business
package Manager Self Service, the budget depletion of internal orders for which the manager
is responsible is displayed on the portal page. The detailed navigation provides the manager
with internal service requests for the application of more internal orders, master data changes,
budget supplements, and adjustment postings.

When a special ISR scenario is accessed, the system displays the request form and all requests
previously submitted by the manager that are in the same category:
The manager can also get a detailed overview of the status of his or her internal service
requests:

For more information, refer to the documentation for the business package Manager Self-
Service in the iView Studio (www.iviewstudio.com).
1.36 ISR MiniApps
You can use ISR MiniApps in all types of intranet or Internet portals. You may want to
modify the layout or design to match that of the portal. To do so, copy the ISR standard
MiniApps and work only with the copies. This prevents your modifications from being lost
when a Support Package is downloaded.
1.36.1 MiniApp: ISR_MY_NOTI
The Internet service ISR_MY_NOTI enables end users to check the status of their requests,
send comments to the processor, and change their requests. This service can be integrated in
the Workplace for an internal employee or as an element of an external portal. Simply copy
the Internet service and adjust the layout and the settings in the list of general parameters as
needed. It can be advantageous to use several MiniApps, each of which is restricted to a
single notification type or scenario. You can also set the parameters of the URL to achieve
this restriction.

The MiniApp displays the short text for the notification created (for a list of short texts, see
Appendix 8.1). The links after the short texts go directly to the original request, to which the
end user can add comments. (You can configure whether the end user can change all request
fields or only add comments. See Appendix 8.1). The status of notification processing and the
entry date are also specified. You can also configure whether the last change date or the
planned end of processing is displayed. This is derived from the priority of the notification.
You can display up to five special characteristics under the short text. This enables you to
separate multiple requests for a single scenario (for example, the destination can identify
several requests on hotel bookings). The possible MiniApp settings are listed as comments in
the HTML template:
<!—
internet service displays an overview of "my notifications" which were
generated from submitted ISR forms.
If you want only notifications for the special notification type XYZ to be displayed you
can call the URL with QMART=XYZ. (.../ISR_MY_NOTI/!?QMART=XYZ )
(No dropdown list is available in this mode)
If you want only notifications for the special scenario ABCD to be displayed you
can call the URL with SCENARIO=ABCD. (.../ISR_MY_NOTI/!?SCENARIO=ABCD )
(No dropdown list is available in this mode)
If you set the parameter DROPFLAG=X (see general parameterlist of ISR_MY_NOTI)

an additional dropdown list is offered - there the user can choose to display all notifications
or only the notifications for a single ISR scenario.
If you set the parameter FINDATFLAG=X (see general parameterlist of ISR_MY_NOTI)

the planned processing date is displayed instead of the last changed date. The processing
date is calculated automatically from priority and can be changed by the processor.
If you set the parameter WITHNUMBER=X (see general parameterlist of ISR_MY_NOTI)

the number of the notification is displayed in the first column.
You can define the selection period with the parameter PASTDAYS (see general parameterlist of
ISR_MY_NOTI). The selection period is from today - pastdays until today. The default of
pastdays is 365 (one year).
If you want to display notifications from all users(!) you can set the parameter

ALLUSER=X (see general parameterlist of ISR_MY_NOTI).
(Caution, please limit the number of displayed notifications in this case
with the help of notification type QMART and selection period PASTDAYS!)
Each notification is displayed with up to five additional characteristics from the ISR form.
The displayed characteristics from the ISR form can be customized in the data base table
QISRCONTROL. If you want to display a characteristic please create entries in
QISRCONTROL following this logic:
1. characteristic:
QISRCONTROL-SCENARIO = <name of scenario in upper case>

QISRCONTROL-FIELD = FIELD1
QISRCONTROL-VALUE = <name of characteristic in upper case>
2. characteristic:

...
5. characteristic:

-->
1.36.2 MiniApps: MA_QM_NOTIFCOM and MA_QM_TASKSCOM
To enable the processor to see an overview in the Workplace of the notifications and tasks
awaiting processing, these MiniApps generate a list of notifications and tasks grouped
according to status (the person placing the request can also use this MiniApp, but he then has
to use the R/3 transactions). You can personalize the selection of notifications. You can define
the selection criteria for the MiniApps in variant maintenance for the worklist transactions
(IQS8 or IQS9). In the MiniApps, you can use the link after the figures to go to the worklist
transactions and access notifications.

1.36.3 MiniApp : Standard Workflow Inbox
If you use the workflow, processors or approvers receive notifications automatically in their
Workflow Inbox. From there, they can go to the notification transaction.

10. Appendix
1.37 Special Customizing Using Table QISRCONTROL
The database table QISRCONTROL is an additional Customizing table for fine-tuning the
individual ISR scenarios. You can define the following settings for each scenario using
transaction SE16. As key fields for each case, specify the client, the scenario, and the
following values for FIELD and VALUE:
FIELD VALUE Comments

NOTIF_SHORT_TEXT Default strategy: The short text for the notification is set
automatically in the first row of the long text for the request
(comments on the request). If the long text is empty, the short
text for the notification is the same as the scenario description.
1 The short text for the request is always the same as the scenario
description.
2 The short text for the request is always the same as the scenario
description with information about the person placing request.
DIRECT_FORM_DISPLAY ALWAYS The original form is always displayed in the notification/task
(extended view) rather than the tabular request view.
ITS_ACTIVE If the transaction is started using ITS (HTML GUI), the original
form is displayed in the notification/task (extended view) rather
than the tabular request view.
FIELD1 <characteristic In the MiniApp ISR_MY_NOTI, selected characteristics are
name> displayed for better identification of the request. Bis zu fünf
FIELD2 <characteristic Merkmale können angezeigt werden
name>
FIELD3 <characteristic
name>
name>
name>
HTML_CTRL_STYLE_SHEET <CSS_Name> If you want to define a custom layout for the tabular request view
displayed in the notification/task, you can define a CSS style
sheet and store it in the Web Repository (transaction SMW0).
The default is CK_ECP_STYLESHEET.
HTML_CTRL_TEMPLATE <HTML_Template> If you want to define a custom layout for the tabular request view
displayed in the notification/task, you can define your own
HTML template and store it in the Web Repository. The default
template is QISR_REQUEST_DATA_TEMPLATE. As a
placeholder, you can use:
<!STYLE!> in place of the CSS style sheet
<!REQUEST_FORM_URL!> in place of the URL for calling the
request form
<!REQUEST_DATA!> for the table of request data
<!HEADLINE!> for the language-dependent “request data“ text
<!REQUEST_FORM_TEXT!> for the language-dependent
“Display request form“ text
You can also substitute a corresponding placeholder for the value

of each special ISR request.
For example, you can replace the <!COLOR!> placeholder with
the value from the ISR characteristic COLOR.
HIDE_EMPTY_FIELDS X If you set this parameter, the tabular request view does not
display ISR characteristics for which no value has been entered.
WF_CREATED <workflow Here you can specify a workflow template for a scenario, which
template> is started when you create the notification. You also need to

enter this workflow template for the BOR object BUS 7051 as an
additional type linkage for event CREATED and function
module QGN01_EVENT_NOTIF_CREATED_ISR for all type
linkages of the event CREATED as a check function.
WF_PROCESS <workflow This is where you can specify a workflow template for a
template> scenario, which is started for the in process again of the
notification. You also need to enter this workflow template for
the BOR object BUS 7051 as an additional type linkage for the
event INPROCESSAGAIN and function module
QGN01_EVENT_NOTIF_PROCESS_ISR for all type linkages
of the event INPROCESSAGAIN as a check function.
JSP_URL <JSP URL> Here you enter the URL for your JSP pages. This enables you to
access the original form from the action box of the notification.
With business package MSS 5.0 in the Enterprise Portal, it is no longer necessary to maintain
the table QISRCONTROL. Instead, you can maintain the Customizing settings with
transaction QISRSCENARIO (pushbutton Additional Data for Scenario) for MSS 50.2 or
with transaction SIMG_SPORT for MSS 50.1. The settings in QISRCONTROL also apply to
the Enterprise Portal if the Customizing transactions mentioned have not been used in MSS
5.0.
1.38 Configuration Settings for Adobe Forms
Additional system settings are necessary before you can use Adobe forms.
ADS Caller:
A destination service is needed to be able to access the form on the back-end system. To do
this, you must configure your local J2EE engine.
You also need a service user ADS_AGENT (password ADOBE) in R/3 for the default client.
This user must be assigned to SAP_BC_FP_ICF. The default client is the client that appears
on the logon screen of the R/3 system as the default value when you log on with the SAP
GUI.
If the user does not exist in the system, you must create it. The user type must be Service. You
can set this in the user transaction on the Logon Data tab).
To configure the J2EE:
Start the J2EE engine administrator and choose Services Destinations.

Create an HTTP destination with the name FP_ICF_DATA.
Choose BASIC authentication and enter the user ADS_AGENT with the password ADOBE
(or the password in R/3).
Adobe WebService:
The Adobe server needs to be configured as well.
Go to Services Web Services Security. Choose Web Service Clients sap.com
tc~wd~pdfobject com.sap.tc.webdynpro.adsproxy.AdsProxy/ConfigPort_Document.
Select Custom for the URL and enter the server or port. The entry should look something like
this:
http://myserver:12345/AdobeDocumentServices/Config?style=document

Select BASIC as the authentication and enter the user ADSuser (case-sensitive) and the
password sapads.
Save your settings.
Start the application tc~wd~pdfobject again.

To do this, go to the Visual Administrator, select Applications (top of the page) and click on
tc~wd~pdfobject. Stop the application and then start it again.
1.39 Configuration Settings for ITS
1.39.1 ABAP Workbench (SE80): Settings for ITS
To specify the URL for test calls (such as http://PGU9C.WDF.SAP-

AG.DE:1080/scripts/wgate) and the ITS instance for publishing the Internet services, choose
Utilities  Settings  ITS. Both entries must point to the same ITS. (Note: Publishing does
not usually work on all ITSs. You must normally select a special ITS.) For the fixed settings
in your system, contact your system administrator.
1.39.2 Setting Up IACOR to Publish the Internet Service
To publish your Internet services from transaction SE80, you need to set up an IACOR
connection between the R/3 system and the ITS. If you have problems publishing your
Internet services, contact your ITS administrator.
1.39.3 General
Table TWPURLSVR (in the component system): for the corresponding logical system (see
client maintenance), the ITS server and port must be entered in this table (such as
myITS.wdf.sap-ag.de:1080).
You can only enter one server for a component system. It is therefore not possible to use more
than one server.
1.40 Predefined Request Fields
For a complete list of predefined ISR request fields, refer to the SAP Library under Cross-
Application Components  Internal Service Requests  Preparing the Internal Service
Request  Definition of an HTML Form  Form Definition.
1.41 Transporting ISR Scenarios
ISR scenarios consist of three components that you transport in different ways:
1. The generated Internet services can be transported using a standard transport request.
2. You transport the Customizing settings for the ISR using standard Customizing
transport requests.

3. You must assign templates created for ISR scenarios incurring costs to a transport
request using transaction QISRTRANSPORT.
The SAP standard for Customizing of notifications (notification types 1–9 and 50–79) is
imported from client 000 to the current client using transaction QISR_SM29. (Note: When
this happens, the standard system overwrites any changes in Customizing for these
notification types.)
1.42 Translating Scenarios and Forms for ITS
You should always enter Internet services in the original language, otherwise problems may
arise due to language dependency. For requests in different languages, use the text elements in
the HTML templates (such as #INFO), whose contents you can define in the original
language in the THEME of the Internet service. You can translate the texts using transaction
SE63.
1.43 Debugging an ISR Scenario with ITS
The flow logic of the ISR request form is controlled by transaction QISR1 (function group
QISR3). This means that transaction QISR1 is always started whenever you access an ISR
scenario. This transaction contains initial screen 100, which however does not normally
appear because the URL call already contains the parameters OKCODE and SCENARIO (and
possibly also REQUEST_NO for displaying and changing a request referring to a
notification). Depending on the OKCODE, the transaction takes you directly to screen 110
(create), 120 (change), or 130 (display). See section 4.1. All standard ISR fields have been
defined and are visible on these screens. The ISR characteristics that you defined are not
displayed because these are directly written or read by the program to the ITS context.
There are two ways to debug an ISR scenario:
 Simplest way: debug in R/3 only

In SE80, start transaction QISR1 (function group QISR3). On the first screen, enter
the ISR scenario in capital letters and (optionally) the notification number, switch the
debugger on by entering /H, and choose Create, Change, or Display. You can now
debug the entire flow logic before the request form is displayed. The system then
displays one of the main screens (110, 120, or 130), which shows the general ISR
fields (ISR_GENERAL_DATA). However, it is not possible to see the special
characteristics (ISR_SPECIAL_DATA) for your scenario, since these are not defined
on the screens. The special characteristics are provided with data directly by the ITS
context, and are thus only visible in the browser. You can still check and/or submit the
request. The special characteristics are then all initial unless you fill them manually in
the debugger (the global object reference to the currently processed request is G_ISR.
This reference has a (private) internal table SPECIAL_DATA. This table contains the
special request data and can be changed if required.
This method of error analysis is completely independent of the ITS and the firewall.

 Debug using the ITS debugger port
The ITS method enables you to debug screen-based Internet services. Start your
Internet service in the browser without the OKCODE or SCENARIO parameters
(example: http://..../scripts/wgate/ZRU01/!). The start screen is displayed. The person
making the request does not see this screen, since the call normally has the OKCODE
and SCENARIO parameters; this means that the start screen is skipped. Once
transaction QISR1 (called for all ISR scenarios) has been started, the start screen is
displayed. You can now log on to R/3 with the debugger port (you can find out the
right one for your R/3 system from your system administrator). This takes you directly
to the corresponding position in transaction QISR1. In the R/3 system, switch the
debugger on by entering /H. Once you have activated the debugger in the debugger
system, you can enter your scenario names on the start screen and then choose Create.
This takes you directly to the point in the program code where initialization for the
scenario starts. You can now debug the flow logic.
If you are interested in analyzing the form logic or submitting the request, start your
request form with the full URL (such as http://.../scripts/wgate/ZRU01/!?
~okCode=CREATE&scenario=RU01). Then start the R/3 debugger port, switch the
debugger on with /H, and trigger an event in the browser (check, submit, or user
command). This enables you to debug the entire ISR scenario including the entry of
special characteristics.
Unfortunately, due to customer firewalls it is often not possible to do this via the
debugger port.
 Output of ITS context:

For testing purposes, you can generate the values for all request fields as a comment
on the HTML page created by ITS. This can be looked at after calling the ISR request
by displaying the source text in the browser. Another parameter must be added to the
URL to call the ISR request:
&~record=1
The must be approved beforehand by the ITS administrator.
 Skipping the check routines when submitting request

If for testing purposes you want to skip all check routines (particularly the BAdI
method INT_SERVICE_REQUEST_CHECK) that are run before a form is submitted,
set parameter QISR to "C" in your fixed user values. Don't forget to delete this
parameter afterwards.
 Error messages: Output error number and message class

For error messages that are output when you submit a form, the notification number
and message class can be displayed instead of the notification text. To do this, set
parameter QISR to "M" in your fixed user values.

1.44 Catalog Profile, Catalogs, Code Groups, and Codes
You assign codes to tasks and actions be able to evaluate them and make specific selections.
You can arrange different codes into code groups. The standard code group SAPISR is
intended for the ISR scenarios. The code group SAPISR is available for tasks (catalog 2) and
actions (catalog 8). You can use a catalog profile to restrict the codes from a code group to a
subquantity for each notification type.
Expand the list of assigned codes according to your requirements in notification Customizing
under Cross-Application Components  Internet/Intranet Services  Internal Service
Request  Scenario Definition  Prepare General Notification  Notification Creation 
Notification Contents  Maintain Catalogs. Then choose the combination of catalog (2 or 8)
and code group (SAPISR) to be processed, and choose ENTER. Select code group SAPISR
and choose Codes on the left-hand side. You can now add more codes.
1.45 Standard SAP Activities and Associated Function Modules
You can use the general function modules of the ISR framework for activities:
 ISR_ACTIVITY_EXECUTE
 ISR_ACTIVITY_EXECUTE_ACTIONDOC
 ISR_ACTIVITY_EXECUTE_TASKDOC
These function modules all call the method EXECUTE_FUNCTION of BAdI QISR4. That is,
the implementation of the desired functionality can be programmed for a combination of the
scenario and the function (import parameter: flt_val, function). This means it is no longer
necessary to define separate function modules in each case with the interface required for the
activities.
You can use the following function modules to access the request form in display or change
mode:
QM06_ND_CHAN_ORIGINAL_TEMPLATE Change ISR form

QM06_ND_SHOW_ORIGINAL_TEMPLATE Display ISR form
You can use the following module to access the Easy Execution Services of ECP (Easy Cost
Planning):
QALK_ISR_AUTO_EXEC Call Execution Services for the task
You can find other function modules using the following generic keys:
QM06_FA* Function modules for actions

QM06_FM* Function modules for tasks
(or general QM06*)
You can use the following function module as a template for a parameterized transaction call:
KWEB_BUDG_ACTION_SUPPLEMENT Performs the budget supplement action

1.46 Methods for Use in the JSP
The following section contains a list of methods available in the JSP (with MSS 5.0).
Explanation of the import parameters:

 Fieldname – Name of the characteristic from the R/3 scenario (Fieldname is of type
String)
 Index – Index number, if multiple values are expected for a characteristic
(Index is of type Integer)
Method Import parameter: Description

Type Name
public String String fieldname, Usage for input help:
getAdditionalData int index Returns the value for the characteristic
(fieldname) and its index (index). The values
are filled in the BAdI
SCENARIO_SET_ADDITIONAL_DATA in
R/3.
public int String fieldname Usage for input help:
getAdditionalDataLength Outputs the number of entries per
characteristic
public String getChecked String fieldname, Usage for checkboxes:
int index Outputs the value for an index for a checkbox
- true, false
String fieldname Usage for checkboxes:
Outputs the value (implicit Index = 1) for a
checkbox - true, false
public String getDisabled String fieldname Access to data of characteristics:
Outputs whether the field on the form for the
specified characteristic is ready for input:
true, false
public String getIsrEvent - Access to general form data:
Returns the value of the triggered event
public String - Access to general form data:
getIsr_form_view Returns the value for the user's role; see
section 5.2.5; ISR_REQUEST,
ISR_PROCESS, ISR_APPROVE
public String getIsr_page - Access to general form data:
Returns the value of the form page.
public String getLabelL String fieldname Access to data of characteristics:
Description, long
public String getLabelM String fieldname Access to data of characteristics:
Description, medium
public String getLabelS String fieldname Access to data of characteristics:
Description, short

public String getMode - Access to general form data:
Returns the value of the request mode of the
form, see section 5.2.4
CREATE, CHANGE, DISPLAY
public String - Access to general form data:
getNewMainJsp Returns the name of the JSP file specified in
the Properties, which is used instead of
IsrMain.jsp (see Note 570417)
public String getNotif_no - Access to general form data:
Returns the notification number (only in
change and display modes)
public String getScenario - Access to general form data:
Returns the value of the form scenario
public String getSelected String fieldname, Usage for input help:
String key, Returns true for the selected value (key) of
int index the characteristic (fieldname) and its index
(index). For other values, false is returned.
The values for the input help are filled in the
BAdI
SCENARIO_SET_ADDITIONAL_DATA in
R/3; see section 5.3
public String getSize String fieldname Access to data of characteristics:
Length of field
public int String fieldname Access to data of characteristics:
getSpecialDataLength Outputs the number of entries per
characteristic
public String String fieldname Access to text:
getTextAreaContent Returns the text for the ID (fieldname); see
section 5.3
public String getValue String fieldname, Access to data of characteristics:
int index Returns the value of a characteristic
(fieldname) and its index (index)
String fieldname Returns the value (implicit Index = 1) for a
characteristic (fieldname)
1.47 Notes Relating to ISR
Note Relevant for Support Packages (SP) Description

396597 Release 4.6C: SP 15 – 17 The Form View and Page fields are not filled in
(before SP 15, the functions of the form BAdIs or in the business HTML template. The BAdI
views are not available) method SCENARIO_SET_FORM_VIEW is not
called.
The solution described in this Note can also be used
when the BAdI methods in the system need to be
regenerated.
515872 Program termination in function module
ISR_CUST_CONTROL_VALUE_GET
543620 Only relevant when business package MSS is used.

With MSS 50.2 and the attached correction, open
requests in the iView Status Overview can be
canceled.
552175 For MSS only: The Note describes what you need to
do to use a date field on the form.
553079 For MSS only: Enables branching to extended
Customizing (replaces table QISRCONTROL; see
section 9.1) from transaction QISRCONTROL.
554644 For MSS only: Enables more than 255 elements to be
displayed in input help, or more than 255 entries per
characteristic to be read from R/3.
570417 For MSS only: Enables you to use your own JSP
instead of modifying the supplied JSP IsrMain.jsp.
580399 For MSS only: Status in the iView Status Overview is
not updated.
582359 For MSS only: The long text formatting is faulty

Copyright
© Copyright 2004 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission
of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software
vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries,
pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or
registered trademarks of IBM Corporation in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered
trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium,
Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented
by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the
world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in
this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies
("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are
those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein
should be construed as constituting an additional warranty.

ISR Cookbook 2004 en

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ISR Cookbook 2004 en

Загружено:

Авторское право:

Доступные форматы

Internal Service Request (ISR)

Copyright © 2000 SAP AG, All rights reserved Page 1 of 83

2.8.2 Applicant with Scenario in Enterprise Portal (Adobe Form)............................12

2.9 Checklist for New ISR Scenarios.............................................................................14

3.2.2 Entry Using Adobe PDF...................................................................................18

3.3 Entry Using JSP iView.............................................................................................18

3.7.2 Defining the Action Box...................................................................................22

Copyright © 1999 SAP AG, All rights reserved Page 2 of 83

4.2.2 Different Layouts Enabled by Additional Themes...........................................25

4.2.3 Different Layouts for Different Request Modes (Create/Change/Display)......26

4.2.4 Layout Based On User Role.............................................................................26

4.2.5 Page Layout and Scrolling Logic......................................................................26

4.2.6 Layout Based On Values of Individual Fields..................................................27

4.3 Elements of the Request Form..................................................................................27

4.3.2 Plain HTML......................................................................................................29

4.4 Initialization, Input Help, Verification, and User Commands..................................32

4.4.3 Programming BAdIs.........................................................................................32

5. Request Form as Java iView in Enterprise Portal 5.0...................................................38

5.2.2 Access to Form Data.........................................................................................43

5.2.3 Layout and HTMLB.........................................................................................43

5.2.4 Different Layouts for Different Request Modes (Create/Change/Display)......43

5.2.5 Layout Based On User Role.............................................................................44

5.2.6 Page Layout and Scrolling Logic......................................................................44

5.2.7 Multiple Languages..........................................................................................45

5.2.8 Layout Based On Values of Individual Fields..................................................45

5.3 Elements of the Request Form..................................................................................45

Copyright © 1999 SAP AG, All rights reserved Page 3 of 83

5.4.3 Programming BAdIs.........................................................................................48

6. Request Form as Adobe Form......................................................................................48

7.4.2 Customizing Standard Roles for the Workflow................................................60

8. Costs and Integration with Controlling.........................................................................63

9.5.2 MiniApps: MA_QM_NOTIFCOM and MA_QM_TASKSCOM....................72

9.5.3 MiniApp : Standard Workflow Inbox...............................................................73

Copyright © 1999 SAP AG, All rights reserved Page 4 of 83

10.3.2 Setting Up IACOR to Publish the Internet Service..........................................76

10.4 Predefined Request Fields........................................................................................76

Copyright © 1999 SAP AG, All rights reserved Page 5 of 83

1.1 Main ISR Terms

Copyright © 1999 SAP AG, All rights reserved Page 6 of 83

1.3 Example Scenario: Applying for a New System User

1.4 General Scenario Data

Copyright © 1999 SAP AG, All rights reserved Page 7 of 83

Copyright © 1999 SAP AG, All rights reserved Page 8 of 83

1.7 Generating the Form (ITS Version)

Copyright © 1999 SAP AG, All rights reserved Page 9 of 83

Copyright © 1999 SAP AG, All rights reserved Page 10 of 83

Copyright © 1999 SAP AG, All rights reserved Page 11 of 83

1.10.1 Applicant with ITS Scenario

http://<your ITS server port>/QISR/!

http://<Ihr ITS Server Port>/ZYYYY/!?~okCode=CREATE&scenario=XXXX

1.10.2 Applicant with Scenario in Enterprise Portal (Adobe Form)

Copyright © 1999 SAP AG, All rights reserved Page 12 of 83

Copyright © 1999 SAP AG, All rights reserved Page 13 of 83

 What is the overall process that needs to be supported?

Copyright © 1999 SAP AG, All rights reserved Page 14 of 83

1.12 General Details

Copyright © 1999 SAP AG, All rights reserved Page 15 of 83

1.13 Request Entry Type

Use the entry type to control how your request is entered:

Copyright © 1999 SAP AG, All rights reserved Page 16 of 83

1.13.1 Entry Using ITS Service

 Generate (SAP Design):