Importing Service Interface Definitions 
You can use service interface definitions or WSDL files in your process model to create message event triggers from them or to assign them to automated activities in the process. You import service interface definitions from the following sources:
Enterprise Services Repository (ESR)
File system or a remote location such as a URL
Services Registry (SR).
Your process model does not directly use the WSDL documents that you import and are contained in your project. The documents are first imported into the Enterprise Service Modeling (ESM) repository, which saves the imported data in its own proprietary format in the rep/wsdl folder of your project. The repository is seamlessly integrated in your project and the import happens in the background.
When you import a WSDL document in your project, a conflict may occur if an interface that was defined in the WSDL had been already imported by another document and the two definitions are different. The difference may be one more or one less operation, change to existing operation input, output or fault message definitions, and so on. Such two documents cannot exist in your project at the same time. Note that the conflicting interface may be defined not in the currently imported document, but in a document referenced by it because when a document is imported, all referenced (imported and included) documents are also imported.
If such a conflict occurs, a dialog prompts you to decide whether or not to continue with the import. If the interface you are importing is a newer version of the existing one, you may continue with the import. The import acts as a reimport of an existing document, so as much information as possible is preserved from the old interface definition. However, all documents that refer to the old interface will be automatically deleted from the repository. The WSDL files are not deleted from the file system and a warning marker appears on them, unless you select the Delete documents from the file system checkbox.
If you need to use both definitions of this interface, choose the No pushbutton when prompted to continue with the import. The file you are trying to import appears in your project with an error marker because it is not imported in the ESM repository. You need to import the current WSDL in another project.
Example
You have the following WSDL documents in your project:
A.wsdl – defines port type “MyInterface”
B.wsdl – defines bindings, imports A.wsdl
C.wsdl – defines service, imports B.wsdl
You want to import D.wsdl, which defines port type “MyInterface”, but its definition is different from the definition in A.wsdl because it contains one more operation. If you choose to continue, A.wsdl, B.wsdl and C.wsdl are deleted from your project and D.wsdl is imported. Since the new version of the interface just adds one more operation, all the existing data is kept and a new operation is added. B.wsdl and C.wsdl need to be deleted because by reimporting the interface they may become invalid.
When you import a WSDL document, a conflict may occur with an entity in its schema. For more information about resolving such conflicts, see Importing XSD files.
Caution
A conflict may occur in case you have an XSD file imported in ESM and try to import a WSDL file with multiple schemas. For example, the imported schema is in a file A.xsd and defines schema with target namespace "http://a". The WSDL is in a file W.wsdl and defines two inline schemas for namespaces "http://a" and "http://b". Now, if the conflicting type, belonging to namespace "http://a" , in the WSDL refers entity from namespace "http://b", an import must be added to A.xsd for namespace "http://b". This conflict cannot be resolved automatically because either there is no schema file for namespace “http://b” or there is more than one.
To resolve the conflict, open the conflicting schema file(s), in this case A.xsd, and add the necessary imports for all required namespaces. This could require creation of the necessary schema files (in this case for example B.xsd) if there are no suitable ones existing. Also make sure that you have added all transitive dependencies (for example the referred entity in namespace "http://b" could refer another entity in "http://c", and so on. Then import/reimport these changes and try again to import the WSDL file.
Prerequisites
You have configured the ESR in the SAP NetWeaver Developer Studio if you want to import service interface definitions from the ESR. For more information, see Browsing Enterprise Services from the SAP NetWeaver Developer Studio.
You have configured the SR in the Developer Studio if you want to import service interface definitions from the SR. For more information, see Configuring the Services Registry.
You have opened the Process Development perspective in the Developer Studio and have expanded your project in Project Explorer view.
Procedure
Expand Process Modeling, then expand Service Interfaces.
In the context menu of the WSDL Files folder, choose Import WSDL...
A dialog box appears, where you specify the output folder and the source for the import. Depending on the option you choose, you see different options on the subsequent screens. The procedures below outline the steps you need to complete to import a service interface definition from each of the locations.
Caution
If you paste a WSDL file in you project which means that you do not use the import wizard, you must switch on the automatic build option in the Developer Studio. Otherwise, the service interface definition is not imported in the ESM repository and appears in your project with a warning marker.
To switch the automatic build option on, choose 
Project 
Build Automatically 
in the Developer Studio.
Importing a Service Interface Definition from the Enterprise Services Repository
Select Enterprise Service Repository and choose the Next pushbutton.
In the dialog that appears, log on to the ESR and choose the Next pushbutton.
Choose a service interface definition to import and choose the Finish pushbutton.
The service interface appears in the Service Interfaces folder and the WSDL file appears in the WSDL Files folder. If the service interface does not appear in the Service Interfaces folder, you have to manually import it:
In the WSDL Files folder, choose the WSDL file of the service.
In the context menu of the WSDL file, choose Reimport.
The service interface definition appears in the \Process Modeling\Service Interfaces folder.
Importing a Service Interface Definition from a Remote Location/File System
Select Remote Location/File System and choose Next.
In the URL field, specify the path to the WSDL file and choose the Finish pushbutton.
Importing a Service Interface Definition from the Services Registry
Select Services Registry and choose the Next pushbutton.
Log on to the SR, if prompted.
Enter your credentials in the Username and Password fields under UDDI Service. The Username and Password fields under Classification Service are automatically populated with the credentials you specify under UDDI Service. Then choose the OK pushbutton.
Specify search criteria to find the Web service whose WSDL file you want to import and choose the Next pushbutton.
Select a service definition from the list.
Log on to the system, which provides the Web service, and then choose the OK pushbutton.
Note
You may need to reimport in the repository a WSDL document which you have already used in the process and you have defined some data mappings for the activities or events that use this WSDL document. A reimport is necessary because the process model may become invalid if the WSDL file has been subsequently modified and, for example, some operations have been deleted.
To trigger the reimport, from the context menu of the WSDL document, choose Reimport and accept the changes shown in the dialog that appears. The new version of the document is imported in the repository and overrides the old one. Thus, you reimport the modified WSDL document from your project in the ESM repository. If you want to reimport the document from its original location, you have to use the Import WSDL... option which is described in the procedure above.
If you choose to reject the changes, the new version of the document is not imported in the repository and hence the document file and the repository are not synchronized. In this case, we recommend that you either make some additional changes and reimport the document, or else revert it to its previous version.
You can choose the Show/Hide Transitive Differences button to see all entities that are not directly changed, but also depend on changed entities.
For more information about configuring the reimport preferences, see Configuring WSDL and XSD Reimport Preferences.
After the reimport, the mapping editor preserves the data mappings for unchanged parameters and removes the data mappings which have become invalid.
(Optional) Creating Service Groups and Service References
You use a Service Group to configure all services included in the group when you deploy your process. To indicate which services belong to a Service Group, you create service references. When you import service interface definitions using one of the options above, you have the option to create a Service Group and a service reference form the import wizard.
After you select a service interface definition to import in the wizard, you choose the Next pushbutton and proceed as follows to create a Service Group and a service reference:
Select the Create new radio button to create a new Service Group. A service reference to this new Service Group is created automatically.
NoteAlternatively, you can select the Choose existing radio button to create a service reference to an existing Service Group. You select the Service Group from the dropdown menu and then choose the Finish pushbutton.
End of the note.Specify a name for the Service Group in the Name field and optionally a description in the Description field.
Select a project in which to create the Service Group from the Project dropdown menu. Choose the Finish pushbutton.
For more information about Service Groups and service references, see Working with Service Groups.