Table of Contents
Where Collaboration fits into SAP NetWeaver
An Overview of the Synchronous Collaboration Framework (SCF)
Jar Files for Developing an SC Service Connector
SCServiceConnector Interface Methods
Getting the Connector Call Back URL from SCF
Storing the Collaboration Session
Ending the Collaboration Session
Development/Implementation of SC Service Connector
Extend AbstractSCServiceConnector
Example Connector for Microsoft NetMeeting
Deployment and Configuration of the SC Service Connector
System Landscape & User Management Configuration
Default Configuration/Pre-configuration
The purpose of this document is to give partners interested in integrating their synchronous collaboration services into the SAP NetWeaver environment an overview about the capabilities of SCF (Synchronous Collaboration Framework) and the requirements for integration with the SCF API toolset.
This document deals in detail with the development/implementation of the Synchronous Collaboration (SC) Service Connector interface, its configuration in SAP Enterprise Portal 6.0 SP2CP, and basic testing. The SCF (Synchronous Collaboration Framework)* interface to be implemented is explained in detail with the help of examples.
*Patent Pending
We assume that the reader has some knowledge of NetWeaver components, Collaboration, and Knowledge Management. We also assume that the reader has access to the SCF Configuration Guide (available at http://help.sap.com -> SAP Netweaver -> SAP Enterprise Portal - > EP 6.0 SP1 -> click on desired language -> New Window Opens -> Choose Administration Guide - > Expand "collaboration" node - > Click on "Synchronous Collaboration Framework") and SCF javadoc. It is also assumed that the reader has programming experience with specific understanding of the Java programming language and general concepts of web programming.
SAP NetWeaver unifies and aligns people, information, and business processes.
Collaboration unifies and aligns people, information, and business processes on a more granular level.
SAP NetWeaver Architecture
SCF Within Collaboration
The Synchronous Collaboration Framework (SCF) is a framework that can be used to integrate various synchronous collaboration tools with applications that can benefit from such integration. In order to integrate client applications with various synchronous collaboration tools, SCF offers two sets of APIs: The Client API and the SC Service Provider API.
The Client API is used by SCF client applications (Communication Framework, various calendars, and other applications that benefit from collaboration features) to access collaboration tools and features integrated with SCF.
The SC Service Provider API is used to develop SC service connectors between SCF and synchronous collaboration tools. This document describes the API and the necessary steps for the development of SC service connectors. As shown in the diagram below (2-1) SCF sits between the client applications and the synchronous collaboration tools.
As well as enabling the unified integration of real-time services into the portal environment, SCF also does the following:
• Synchronizes with groupware clients
• Allows information from groupware clients (for example, attachments in meeting requests) to be automatically pulled into online meetings
• Adds persistence and context to the online session results
• Supports the capturing, distribution, and retrieval of session results by utilizing the KM services of the Knowledge Management platform
The following screenshots give an overview of the different methods of integration. After a look at each method in detail, a graphic shows where the integration takes place in an architectural context of the KM platform.
Graphic 1: Example of how to start an ad-hoc application sharing session by mouse click from the CLP (Collaboration Launch Pad)
Graphic 2: Example of how to schedule a WebEx meeting center session from the unified portal calendar
Graphic 3: Synchronized with the groupware client in question (here: Microsoft Outlook)
Graphic 4: Meeting/Session History Data Viewer
Any online meeting (independent of the selected service provider) can be launched, joined, or edited either directly in the portal or from the respective groupware client (see graphic 3). When ending an online meeting, SCF persists the information, along with attachments* and session recordings*, and allows the usage of all KM services in combination with the persisted meeting content.
* If the SC service connector also provides these services
Clients Connectors Service Providers
Graphic 5: SCF Overview
SCF adds persistence and context to online meeting services. What this means is that meeting content cannot only be reviewed and revisited, it also allows adding context to the meeting results, thereby extending the meeting beyond its 'real-time' end time.
To develop a SC Service Connector you need to create a portal component and export it as a PAR file. Make sure you add the the following jar files to the class path (java build path - libraries in Eclipse)
The SC Service Provider API consists of a set of classes and interfaces that can be used by an SC service connector to interact with SCF
|
Class/Interface |
Description |
|
SCServiceConnector |
This interface declares the main methods that SCF can call on an SC service connector. |
|
AbstractSCServiceConnector |
This abstract class defines some additional methods that are used for connector initialization as well as some methods that allow the
connector to communicate with SCF. Since this class extends |
|
SCFException |
An SC service connector can use this class for signaling problems in its operation. |
|
SCSession |
|
|
ProviderSession |
Used by an SC service connector to communicate to SCF about SC session data that an SC provider application is aware of. This interface exposes all relevant data needed by an SC service connector to prepare, schedule, start, and join an SC session. |
|
UserInfo |
Exposes all relevant user data needed by an SC service connector for authenticating a user with an |
In order to develop an SC service connector, you need to develop a portal component that contains a class that extends the
AbstractSCServiceConnector class.
The AbstractSCServiceConnector class implements the SCServiceConnector interface and declares some methods of its own. Below are the
descriptions of the methods that an SC service connector needs to implement.
|
Methods |
Description |
|
|
This method is called by the SCF in the process of setting up (scheduling or preparing) an SC session. The connector can use this method to schedule the session with the SC service provider. (Optionally, an SC service connector can provide an empty implementation for this method). |
|
|
This method is called by the SCF in the process of modifying a scheduled SC session. The connector can use this method to notify an SC service provider of scheduling changes. (Optionally, an SC service connector can provide an empty implementation for this method). |
|
|
This method is called by the SCF in the process of canceling a scheduled SC session. The connector can use this method to notify the SC service provider that the session has been canceled. (Optionally, an SC service connector can provide an empty implementation for this method) |
|
|
This method is called by the SCF in the process of starting or joining an SC session. |
|
Methods |
Description |
|
|
This method is similar to the |
|
|
This method saves the provider session data in the SCF repository. |
|
|
This method retrieves the provider session from the SCF repository. |
|
Used by SCF to set the provider name and URL. The connector itself does not use it. |
|
Returns the name of the provider. This method is used by SCF. |
|
Returns the URL of the provider. This method is used by SCF. |
Some service providers only allow hosts to start sessions. The methods below can be used to determine if the user can start or join a session
|
Methods |
Description
|
|
|
This method is used to find out whether the user is a host. It returns a Boolean value. |
|
|
This method is used to find out if the user is a participant. It returns a Boolean value. |
Implementation note:
The above two methods can call the following method to get the logged on user.
IUser user = (com.sap.security.api.IUser)request.getUser();
A list of participants and hosts can also be obtained from the ProviderSessionobject. The ID of the logged on user can be found in the list of
hosts or list of participants.
The SC service connectors use the ProviderSession interface for setup data, start data, and to report state information to an
SCSession instance. The service provider server needs to call its connector when a meeting starts successfully and at the end of meeting to let
SCF know these two times . Note that you need to call commit() after setting attributes to
ProviderSession, but only if the code is in the doContent() method. The next section explains how to set up
the end time.
Example: Setting up meeting start and end times
protected void doContent(IPortalComponentRequest request,
IPortalComponentResponse response) {
ProviderSession providerSession = (ProviderSession) session.getAttribute("providerSession");
// the session's parameter (service providers identifier) is set by the connector at session start.
String action= request.getParameter("action");
String scSessionId= request.getParameter("scSessionId");
String providerSessionId= request.getParameter("providerSessionId");
// request's parameter is to be set by the service provider
…
…
if (action.equals("sessionstart") {
// just to illustrate, the connector needs to use its own parameters
providerSession = getSCFRepository().getProviderSession(scSessionId, request);
providerSession.setProviderSessionId(providerSessionId);
providerSession.setTimeSessionStarted(new Date());
commit(providerSession, request);
actionUrl = getStartMeetingUrl(request, providerSessionId, scSessionId);
request.getServletResponse(true).sendRedirect(actionUrl);
}
if (action.equals("sessionend") {
providerSession.setTimeSessionEnded(new Date());
commit(providerSession, request);
//close the window, do clean up…
}
…
…
}
|
Type of operation |
Description |
|
|
The setup data is used to provide the SC service connector with the information necessary to set up a session. One of the properties available to the SC service connector using this interface is SCServiceTypeId (see 11.3.2 for details). This property allows a connector to provide more than one service type. For example, RTC provides chat and application sharing services. If the value for SCServiceTypeId is 'application sharing', the RTC connector sets up an application sharing session. If the value is 'chat', it sets up a chat session. Refer to the SCF javadocs for details on this interface.
|
|
|
|
|
|
The properties that make up the state data are used to keep state information about an SC session once it has been set up. The
|
The connector implementation may require its own URL to pass on to the service provider so that the service provider may call back the connector. Here is how the URL can be constructed:
protected String calculateCallbackURL(
ProviderSession session, IPortalComponentRequest request) {
String callbackURL = getFullComponentUrl(request,
getProviderComponentName(request));
// Append action parameters to callback URL.
// These are later parsed in doContent
callbackURL = callbackURL
+ "?action=" //connector specific parameter(s)
+ END_SESSION
+ "&sessionid="
+ session.getSCSessionId();
return callbackURL;
}
The connector needs to set the session end time when the collaboration session ends. On receipt of this notification from the connector, SCF asks the hosts of the collaboration session whether the session that just ended needs to be stored in the session history.
At the end of the collaboration session, the service provider redirects to the connector and the connector then executes the following code in order to set the end time of the session. The connector URL (can be created by calling the getFullComponentUrl(request, getProviderComponentName(request)) method in the connector) can be passed on to the service provider by the connector at the start of the meeting.
protected void doContent(IPortalComponentRequest request,
IPortalComponentResponse response) {
ProviderSession providerSession = (ProviderSession) session.getAttribute("providerSession");
// the sessions's parameter (service providers identifier) is set by the connector at session start.
String action= request.getParameter("action");
String scSessionId= request.getParameter("scSessionId");
…
…
if (action.equals("sessionend") {
providerSession.setTimeSessionEnded(new Date());
commit(providerSession, request);
}
…
…
}
At the end of the session, SCF asks the connector for session attachments such as session documents and session recordings. Since SCF can call this method
at any time after the end of the meeting, it is imperative that the service provider stores the attachments permanently (retrievable by provider session ID).
If the service provider of the connector supports such a feature, the connector overrides the following method of the AbstractSCServiceConnector
class.
public Enumeration enumerateAttachments(String providerSessionId)
SCF calls this method after the connector notifies SCF of the end of the collaboration session. SCF passes the provider session ID and expects enumeration of com.sap.ip.collaboration.sync.api.scf.service.Content type objects.
*Content is a simple container for holding the byte array and the mime type of the attachment
Example:
Byte[] attachment = <get attachment(s) /session recording from the service provider> Content c = new Content(attachment, "text/html",name); //create an Enumeration of and return.
* If the service provider is not capable of storing the session recordings or attachments permanently, the following methods in the
ProviderSession interface can be used
/**
* Saves binary data as session attachment
*
* @param content byte array of binary data
* @param name name of the attachment
* @param mimeType mime type of the contents. mimeType example : "text/html"
* @param extended_properties map of the extended properties, if any. Optional
*
*/
public void addBinaryContentAsAttachment(byte[] content,
String name,
String mimeType,
Map extended_properties);
/**
* Saves link as session attachment
*
* @param linkUrl External link/url to the resource (example: http links)
* @param name name of the attachment
* @param extended_properties map of the extended properties, if any. Optional
*/
public void addURLAsAttachment(String linkUrl,
String name,
Map extended_properties);
This section describes how SCF handles unexpected situations. There are many reasons for which exceptions can occur, but the sources of these exceptions can be categorized as internal and external. If SCF, because of its own rules, decides that a request cannot be served, then it raises an internal exception. On the other hand, if a request cannot be handled for reasons outside SCF's control, then SCF raises an internal exception and chains it to this external exception. In the latter case, the internal exception contains a message that is SCF's interpretation of the external exception.
SCFException, shown below, is the class that is currently responsible for all SCF exceptions.
Graphic: SCFException Class Diagram
This class extends the BaseException class, which provides the functionality for the following:
SCFException.
SCFException also provides a set of keys that either SCF or SC service connectors can use when raising this exception. An example of such a key
is KEY_SESSION_ENDED, which is shown in the SCFException class graphic above.
This section examines an example of code for the SC service connector
Import the main SCF and portal packages required for the connector. For more information on these packages, refer to the JavaDoc.
import com.sap.ip.collaboration.core.api.scf.client.SCSessionManagerFactory; import com.sap.ip.collaboration.core.api.scf.exception.SCFException; import com.sap.ip.collaboration.core.api.scf.service.ProviderSession; import com.sap.ip.collaboration.core.api.scf.service.UserInfo; import com.sap.ip.collaboration.core.api.util.text.TextBundle; import com.sap.ip.collaboration.sync.api.scf.service.AbstractSCServiceConnector; import com.sap.tc.logging.Location; import com.sapportals.portal.prt.component.IPortalComponentRequest; import com.sapportals.portal.prt.component.IPortalComponentResponse; import com.sapportals.portal.prt.component.IPortalComponentURI; import com.sapportals.portal.prt.logger.Level; import com.sapportals.portal.prt.session.IUserContext;
Each SCServiceConnector must extend AbstractScServiceConnector. This class extends the AbstractPortalComponent, which
enables it to communicate with Synchronous Collaboration Service providers using the HTTP protocol.
public class NewServiceConnector
extends AbstractSCServiceConnector {
public void setupSCSession(ProviderSession providerSession,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException {
}
public void updateSCSession(String provideSessionId,
ProviderSession providerSession,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException {
}
public void cancelSCSession(String providerSessionId,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException {
}
public void addUserToSCSession(ProviderSession providerSession,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException {
}
}
Each of the above four methods of AbstractSCServiceConnector needs to be implemented by the new SC service connector.
This method is called by SCF when the client calls the corresponding method in SCF. If this method call is successful, SCF returns the session ID to the client. The connector can use this method to check resources, permissions, and authentications, or to set up a session in the service provider, amongst other things. Lots of information can be retrieved from input objects by the connector. The implementation of this method can be left blank if the connector does not want to make any checks before the start of the session.
public void setupSCSession(ProviderSession providerSession,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException {
//getting info about the session
String hosts = providerSession.getHosts ();
String participants= providerSession.getParticipants ();
Date startTime = providerSession.getStartTime();
String username = userInfo.getUserName();
String password = userInfo.getPassword();
String actionUrl = getProviderServerUrl() + username +password;
request.getServletResponse(true).sendRedirect(actionUrl);
}
This method is called when the client needs to update meeting parameters. The implementation can be left blank if the connector does not need to do any processing for the session update.
This method is called when the client needs to cancel the meeting/session. The implementation can be left blank if the connector does not need to do any processing to cancel the session at service provider end.
This method adds the user to the session. This method is used either for starting the session as a host or joining the session as a participant. SCF calls this method when a user needs to be added to the ongoing session. In turn, the connector can call the provider and pass the required information to the service provider.
public void addUserToSCSession(ProviderSession providerSession,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException {
//getting the id of the session which was provider by the service provider.
String sessionId = providerSession.getSCSessionId();
String serviceTypeId = providerSession.getSCServiceTypeId();
//getting service provider user mapping info. Please refer to section 11.2
String username = userInfo.getUserName();
String password = userInfo.getPassword();
String providerUrl = getProviderServerUrl();
String actionUrl = providerUrl + username +password +sessionId;
request.getServletResponse(true).sendRedirect(actionUrl);
}
The following code statements get the user information needed for the connector to authenticate the user with its service provider. This information cannot be used by service providers that have single sign-on enabled and therefore do not require additional user information.
String username = userInfo.getUserName(); String password = usrInfo.getPassword();
package com.sap.ip.collaboration.sync.api.scf.connector;
import java.io.IOException;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Date;
import java.util.Iterator;
import com.sap.ip.collaboration.core.api.scf.exception.SCFException;
import com.sap.ip.collaboration.core.api.scf.service.ProviderSession;
import com.sap.ip.collaboration.core.api.scf.service.UserInfo;
import com.sap.ip.collaboration.sync.api.scf.service.AbstractSCServiceConnector;
import com.sap.security.api.IUserMaint;
import com.sap.security.api.UMException;
import com.sap.security.api.UMFactory;
import com.sap.tc.logging.Location;
import com.sapportals.portal.prt.component.IPortalComponentRequest;
public class NetMeetingConnector extends AbstractSCServiceConnector {
public void setupSCSession(ProviderSession providerSession,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException{
}
public void updateSCSession(String providerSessionId,
ProviderSession providerSession,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException {
}
public void cancelSCSession(String providerSessionId,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException {
}
public void addUserToSCSession(ProviderSession providerSession,
UserInfo userInfo,
IPortalComponentRequest request)
throws SCFException {
Collection attendees = providerSession.getAttendees();
if (thereAreNoAttendees(attendees)) {
attendees = new ArrayList();
attendees.add(request.getUser().getUniqueID());
providerSession.addAttendees(attendees);
showNetMeeting(request);
providerSession.setTimeSessionStarted(new Date());
} else { //if someone has already started, then join that user.
Iterator iterator = attendees.iterator();
String hostId = (String) iterator.next();
String currentUserId = request.getUser().getUniqueID();
if(currentUserId.equals(hostId)) {
showNetMeeting(request);
} else {
String hostEmail = getUserEmailFrom(hostId);
providerSession.getAttendees().add(currentUserId);
showNetMeetingAndCallTo(hostEmail, request);
}
}
}
private boolean thereAreNoAttendees(Collection attendees) {
if (attendees == null) {
return true;
}
if (attendees.isEmpty()) {
return true;
}
return false;
}
private String getUserEmailFrom(String userId)
throws SCFException {
try {
IUserMaint user = UMFactory.getUserFactory().getMutableUser(userId);
return user.getEmail();
} catch (UMException e) {
throw new SCFException("getUserEmailFrom", e, Level.SEVERE);
}
}
private void showNetMeeting(IPortalComponentRequest request)
throws SCFException {
StringBuffer page = new StringBuffer(500);
page.append("<html>");
page.append(" <head>");
page.append(" <meta http-equiv=\"content-type\" content=\"text/html\" />");
page.append(" <title>SAP NetMeeting</title>");
page.append(" </head>");
page.append(" <body>");
page.append(" <object ID=NetMeeting CLASSID=\"CLSID:3E9BAF2D-7A79-11d2-9334-0000F875AE17\">");
page.append(" <PARAM NAME = \"MODE\" VALUE = \"Full\">");
page.append(" </object>");
page.append(" </body>");
page.append("</html>");
try {
request.getServletResponse(true).getWriter().print(page);
} catch (IOException ioe) {
throw new SCFException("showNetMeeting", ioe, Level.SEVERE);
}
}
private void showNetMeetingAndCallTo(String hostEmail,
IPortalComponentRequest request)
throws SCFException {
StringBuffer page = new StringBuffer(500);
page.append("<html>");
page.append(" <head>");
page.append(" <meta http-equiv=\"content-type\" content=\"text/html\" />");
page.append(" <title>SAP NetMeeting</title>");
page.append(" </head>");
page.append(" <body onload=NetMeeting.CallTo(\"");
page.append(getProviderServerUrl(request));
page.append('/');
page.append(hostEmail);
page.append("\")>");
page.append(" <object ID=NetMeeting CLASSID=\"CLSID:3E9BAF2D-7A79-11d2-9334-0000F875AE17\">");
page.append(" <PARAM NAME = \"MODE\" VALUE = \"Full\">");
page.append(" </object>");
page.append("<p>Params<p>remoteAddr: " + request.getServletRequest().getRemoteAddr()
+ "<p>remoteHost: " +request.getServletRequest().getRemoteHost());
page.append(" </body>");
page.append("</html>");
try {
request.getServletResponse(true).getWriter().print(page);
} catch (IOException ioe) {
throw new SCFException("showNetMeetingAndCallTo", ioe, Level.SEVERE);
}
}
}
For testing purposes, you need Microsoft NetMeeting installed on the client machine. Microsoft NetMeeting is available with recent versions of Windows operating systems. It can also be downloaded from http://www.microsoft.com/windows/netmeeting/. This code has been tested with Microsoft NetMeeting version 3.20.
This section describes the following:
To deploy a portal component in the portal, a portal archive (PAR) file needs to be built. The par file is a ZIP file with the extension .par. Ant should be used to build the component into a PAR file. For more information on how to build and deploy the portal component, refer to the PDK documentation.
The SC service provider may require users to authenticate themselves (to the SC service provider in question) before they are allowed to access these services. The SC service connector indicates this in the pre-configuration of the connector. Refer to sections 11.3.2.1.1 and 11.3.2.1.3.
Note: The above steps can be skipped if your connector does not require external authentication.
Entering User Mapping Information
Add an "application-config" tag (within the "application" tag), as follows to the portalapp.xml. This tag is automatically generated by the pdk plug-in.
Proper system entries need to be put. Refer PDK documentation for more information. The sample system entry :-
<application-config>
<property name="releasable" value="false" />
<property name="ServicesReference" value="="com.sap.netweaver.kmc.util,com.sap.netweaver.coll.appl.sync,com.sap.portal.usermanagement,com.sap.netweaver.coll.shared,com.sap.portal.usermanagement,com.sap.portal.usermapping" />
<property name="PreservedConfigPaths" value="" />
</application-config> <components> <component name="NewConnector"> <component-config> <property name="SecurityZone" value="com.sap.portal/low_safety" /> <property name="AuthRequirement" value="user" /> <property name="ClassName" value="NewConnector" /> <property name="SafetyLevel" value="low_safety" /> <property name="ResourceBundleName" value="" /> </component-config> <component-profile/> </component> </components>
A connector can register the default service provider and service types configuration automatically at the time of loading into
the portal. The default configuration can be edited using the steps described in the next section (Manual Configuration). Follow the steps below to make
the default configuration available.
Create a class that extends com.sap.ip.collaboration.core.api.fwk.portal.GenericService. Call the following methods of the
SCConfiguration class in the init() method:
createSCServiceProviderConfigurable(String connectorId, String connectorParName, String url, boolean usermapping)
connectorId: Unique ID of the Connector
connectorParName: Name of the connector's par to be deployed in the portal
url: URL of the provider server to be contacted, for example, (for RTC: local host or the server on which the
application server is installed)
monitoringClass: Fully qualified name of the monitoring class. See section Error! Reference source not found..
usermapping: True if user mapping is required for the service provider, false otherwise. False if single
sign on from the portal to the connector service provider is available.
createSCServiceTypeConfigurable(String scserviceTypeId, String displayNameKey, String defaultSCService)
Must be called in order to register each service type.
scserviceTypeId: Unique ID of the service type.
displayNameKey: ResouceBundle (of the connector) key to be used by SCF to retrieve the display name of the service type from
the connector in the language of the user.
defaultSCService: The service provider that provides this service. See the connectorId parameter of the
createSCServiceProviderConfigurable method (described above).
package com.sap.ip.collaboration.sync.api.scf.connector;
import com.sap.ip.collaboration.core.api.fwk.portal.GenericService;
import com.sap.ip.collaboration.sync.api.scf.service.SCConfiguration;
import com.sap.tc.logging.Location;
import com.sapportals.portal.prt.service.IServiceContext;
import com.sapportals.portal.prt.service.ServiceException;
public class ConnectorConfiguration
extends GenericService {
public void init(IServiceContext serviceContext) {
super.init(serviceContext);
try {
SCConfiguration scfConfiguration = new SCConfiguration();
// registering Service Provider in SCFConfiguration
scfConfiguration.createSCServiceProviderConfigurable(
"RTC",
"com.sap.netweaver.coll.appl.sync.RTCConnector",
"http://localhost",
false
);
// registering Service Types in SCFConfiguration. For each service type //this method should be called
scfConfiguration.createSCServiceTypeConfigurable("RTC_ApplicationSharing", "ApplicationSharing", "RTC");
scfConfiguration.createSCServiceTypeConfigurable("RTC_Chat", "Chat", "RTC");
}
catch (Exception e) {
throw new ServiceException(className + "initialization failed:", e);
}
}
}
Add the service to portalapp.xml
<services>
<service name="ConnectorConfig">( ConnectorConfig is the unique identifier for the connector)
<service-config>
<property name="className" value="com.sap.ip.collaboration.sync.api.scf.connector. ConnectorConfiguration"/>
<property name="classNameFactory" value=""/>
<property name="classNameManager" value=""/>
<property name="poolFactory" value="0"/>
<property name="startup" value="true"/>
</service-config>
<service-profile>
<property name="generic_classloader_registration" value="yes"/>
<property name="generic_so_registration" value="no"/>
<property name="generic_service_key" value="
"/> </service-profile>
</service>
</services>
(Refer to the EP6 SCF Admin Guide for detailed step-by-step information)
Configuration is to be carried out using the Knowledge Management configuration component of the portal. To configure SCF, the component
com.sap.netweaver.coll.appl.syncneeds to be available in the portal. For more information, refer to the SCF Configuration section in the
SCF Admin Guide. Some of the attributes values (such as service provider URL) created by pre-configuration steps need to be changed manual.
Configuration for SCF can be found under
Configuration -> Collaboration -> Synchronous Collaboration Services
Synchronous collaboration services have two different folders for configuration
Graphic: Configuring the SC Service Provider
There are the following three configuration classes:
Graphic: SCF Service Registry
This are should be used to configure service providers. You can create, edit, view or delete SC service. The attributes you need to configure are as follows:
Graphic: Configuring the SC Service Provider
This should be used to configure all available service types or SC service Types that are provided by the SC service. The attributes that you need to configure are as follows:
Graphic: Available Service Types
The client cannot use all the service types that a provider provides; only activated service types can be used by clients. The service types can be activated as follows:
Graphic: Activating Service Types
Graphic: Testing the New SC Service Connector