SAP ISR Cookbook 2004

Internal Service Request (ISR)Cookbook

How to Create Service Request Scenarios

July 2004Stephan Rehmann, Martin Kreyscher, Dirk Ahlert

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

Workflow Processing

Approve Request

Cost of request is automatically determined (Easy Cost Planning) and the processor can trigger automatic purchase order generation (Easy Execution)

One or more processors carry out actions (for example, creating automatic correspondence or R/3 transactions)

Web Form

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................................................................................................122.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..................................................................................................163.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.........................................................................................................213.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......................................................................254.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..................................................................................274.3.1 SAP Design with Business HTML...................................................................27

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

4.4 Initialization, Input Help, Verification, and User Commands..................................324.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.........................................................................................................415.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.........................................485.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.........................597.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...........................................................................................................709.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.................................................................................7610.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

2.1 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.

2.2 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.


2.3 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.


2.4 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).

2.5 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.


2.6 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).

2.7 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.


2.8 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.

2.8.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).

2.8.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.

2.8.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.


2.9 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.

3.1 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.

3.2 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 TransactionEntry with the usual SAP entry screen for general notifications (HTML-GUI).

Entry Using Adobe PDFYou can define special characteristics here. You can generate the Adobe form or (if it already exists) enter it directly.

Entry Using JSP iViewYou can define special characteristics here. You can generate the JSP form or (if it already exists) enter it directly.

Entry Using BSPYou 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.

3.2.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.

3.2.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).

3.3 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).


3.4 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.

3.5 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.

3.6 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.)


3.7 The Action Box

3.7.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.

3.7.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.

3.8 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)

4.1 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.

4.2 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.

4.2.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.

4.2.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).

4.2.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.

4.2.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.


4.2.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” )` ìnclude(~theme="99", ~language="", ~name="page2.html")` èlsif ( ISR_PAGE == “3” )` ìnclude(~theme="99", ~language="", ~name="page3.html")` è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 forwardPREV_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.

4.2.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")`


4.3 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).

4.3.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 color?", left=4, top=0, labelWidth=0 )`

`SAP_ISRRadioButton( id="13", name="COLOR", value="blue", text="or the blue color?", left=4, top=0, labelWidth=0 )`

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_ISRGroupBox(x , y , 069, 010, #comment)` `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_ISRGroupBox(x , y , 069, 005, #comment)` `SAP_ISRLongTextOutput(cols=67, rows=5, left = x+1, top = y+1 );` `y = y + 6;` ènd;`

ButtonsThe 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 )`

PositioningAll 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( ) `

4.3.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.

PositioningEach 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")`>

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?";`

<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>

`CheckboxProlog("COLOR[2]")`<input name="COLOR[2]" value="green" type="checkbox"`Checked("COLOR",2,"green")` `disabled("COLOR")`>and the green color? <br>


`CheckboxProlog("COLOR[3]")`<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_TEXTThe 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. 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`


<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')">

4.4 Initialization, Input Help, Verification, and User Commands

4.4.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

4.4.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)

4.4.3 Programming BAdIs

4.4.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:


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.


4.4.3.2 Data Structure in the ISR Framework

You can use the following standard ISR data structures for implementing BAdI methods:

Name CategoryDescription

FLT_VAL QSCENARIOCurrent scenario

MODE QISRDMODECurrent processing mode (CREATE, CHANGE, DISPLAY); corresponds to the template parameter ISR_MODE

FORM_VIEW QISRDFORMVIEWCurrent form view (ISR_PROCESS or ISR_REQUEST), corresponds to the template parameter ISR_FORM_VIEW

PAGE QISRDFORMPAGECurrent page number; corresponds to the template parameter ISR_PAGE

GENERAL_DATA QISRSGENERAL_PARAMGeneral ISR data (requested by, entered by, priority, notification short text, etc.)

SPECIAL_DATA QISRTSPECIAL_PARAMTable 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_PARAMAdditional table for input help values etc., which can be used as needed

USER_COMMAND* SYUCOMMThe last command that was triggered on the form

RETURN* BAPIRET1Return structure for error messages

* only in BAdI method SCENARIO_PROCESS_USER_COMMAND

4.4.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_STRUCMoves 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_DATASame 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

5.1 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.

5.2 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>


5.2.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" />

5.2.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") %>

5.2.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" %>

5.2.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"

/> <% } %>

5.2.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) { %><hbj:button id="SEND" 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.

5.2.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.


5.2.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.

5.2.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") %>' /> <% } %>

5.3 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") %>' />

Dropdown list box (input help) for the characteristic 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" disabled='<%= ISR.getDisabled("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" disabled='<%= ISR.getDisabled("COLOR") %>' 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" disabled='<%= ISR.getDisabled("COLOR") %>' 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_TEXTThe 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, 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" />


<hbj:button id="CHECK" text="Check" tooltip="Submit ISR-Form" onClick="submit" design="emphasized" /> <hbj:button id="SEND" 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 fieldPrerequisite: 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") %>'

/>

PositioningHTMLB 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:gridLayoutCell rowIndex="1" columnIndex="2"> <hbj:textView text='<%= ISR.getValue("NOTIF_NO_OUT") %>'/> </hbj:gridLayoutCell> <hbj:gridLayoutCell rowIndex="2" columnIndex="1"> <hbj:textView text="RETURN-MESSAGE" design="LABEL"/> </hbj:gridLayoutCell> <hbj:gridLayoutCell rowIndex="2" columnIndex="2"> <hbj:textView text='<%= ISR.getValue("RETURN-MESSAGE") %>'/> </hbj:gridLayoutCell> </hbj:gridLayout>

5.4 Initialization, Input Help, Verification, User Commands

5.4.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

5.4.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.

5.4.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 processingapp.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 accessif($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 inputo when the form is displayed in the perspective Review and Submito 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 applicationsExample: Personnel Change Request (PCR) in the Business Package MSS

Indirect integration through a scenario groupScenario 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

7.1 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.

7.2 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 processingThis workflow template is always started when a general notification is created (event CREATED) or processed again (event INPROCESSAGAIN).

20001028 - Workflow template for task processingThis 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 Cross-Application Components Internet/Intranet Services Internal Service Request Scenario Definition Prepare General Notification Notification Processing Activate Workflow Template and Assign Processor Assign Agents.

7.3 Partner Functions and Partner Determination Procedures

Notification processing can involve various people with different functions. The predefined functions for ISR are:

AB = Responsible DepartmentOrganizational unit responsible for processing the request

AO = AuthorUser 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 = ApproverUser who approves the notification

§P = Task ProcessorUser 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.

7.4 Processor Determination from the Standard Role in the Workflow

7.4.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 Cross-Application Components Internet/Intranet Services Internal Service Request 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.)

7.4.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.

9.1 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.

9.2 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.

9.3 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.

9.4 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).

9.5 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.

9.5.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.


http://www.iviewstudio.com/

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 youcan 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 youcan 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 notificationsor 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 processingdate 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 ofpastdays 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 casewith 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 tableQISRCONTROL. 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 = FIELD1QISRCONTROL-VALUE = <name of characteristic in upper case>

2. characteristic:


...

5. characteristic:


-->

9.5.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.


9.5.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

10.1 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 CommentsNOTIF_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 name>

In the MiniApp ISR_MY_NOTI, selected characteristics are displayed for better identification of the request. Bis zu fünf Merkmale können angezeigt werdenFIELD2 <characteristic

name>FIELD3 <characteristic



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 template>

Here you can specify a workflow template for a scenario, which 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 template>

This is where you can specify a workflow template for a 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.

10.2 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.

10.3 Configuration Settings for ITS

10.3.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.

10.3.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.

10.3.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.

10.4 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.

10.5 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.)

10.6 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.

10.7 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 onlyIn 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 portThe 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 requestIf 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 classFor 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.


10.8 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.

10.9 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_TASKDOCThese 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 formQM06_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 actionsQM06_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


10.10 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:Type Name

Description

public String getAdditionalData

String fieldname, int index

Usage for input help: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 getAdditionalDataLength

String fieldname Usage for input help:Outputs the number of entries per characteristic

public String getChecked String fieldname, int index

Usage for checkboxes: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 getIsr_form_view

- Access to general form data: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.4CREATE, CHANGE, DISPLAY

public String getNewMainJsp

- Access to general form data: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, String key, int index

Usage for input help:Returns true for the selected value (key) of 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 getSpecialDataLength

String fieldname Access to data of characteristics:Outputs the number of entries per characteristic

public String getTextAreaContent

String fieldname Access to text:Returns the text for the ID (fieldname); see section 5.3

public String getValue String fieldname, int index

Access to data of characteristics:Returns the value of a characteristic (fieldname) and its index (index)

String fieldname Returns the value (implicit Index = 1) for a characteristic (fieldname)

10.11 Notes Relating to ISR

Note Relevant for Support Packages (SP) Description396597 Release 4.6C: SP 15 – 17

(before SP 15, the functions of the form views are not available)

The Form View and Page fields are not filled in BAdIs or in the business HTML template. The BAdI 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.