Get Started Developing with the Java API of the ECM ... · PDF fileHow SAP NetWeaver -To Guide...

SAP NetWeaver

How-To Guide

Get Started Developing with the

Java API of the ECM Infrastructure

Applicable Releases:

SAP NetWeaver CE 7.2

Version 1.0

May 2010

© Copyright 2010 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, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated 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, SAP NetWeaver, 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.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

SAP NetWeaver “How-to” Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, clarification or support, please refer to SAP Consulting.

Any software coding and/or code lines / strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

Disclaimer

Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components.

Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not be modified or altered in any way.

Table of Contents

1. Business Scenario .......................................................................................................... 1

2. Background Information ................................................................................................. 1

3. Step-by-Step Procedure .................................................................................................. 2

3.1 Setting up the Development environment .................................................................. 2

3.1.1 Create a new Development Component (DC) for your project ....................... 2

3.2 Introduction to the ECM Java API ............................................................................. 3

3.2.1 Login to the ECM Store................................................................................. 3

3.2.2 Files, folders and external links in the repository ........................................... 4

3.2.3 Accessing the metadata (properties) of ECM objects .................................... 6

3.2.4 Basic functions – Copy, move and delete ...................................................... 6

3.3 A first ECM Application – An ECM Navigation Cloud ................................................. 7

3.3.1 Create the Java Web Module ........................................................................ 8

3.3.2 Implement the application logic ................................................................... 10

3.3.3 Deploy and run the example application ...................................................... 11

4. Restricting Access to Files and Folders....................................................................... 14

4.1 Restricting Access to a File ..................................................................................... 14

4.2 Privileges ................................................................................................................ 15

4.3 Other ACL related Methods..................................................................................... 16

4.4 Checking Privileges ................................................................................................ 16

5. Locking .......................................................................................................................... 17

5.1 General .................................................................................................................. 17

5.2 Lock a node ............................................................................................................ 17

5.3 Unlock a node......................................................................................................... 18

5.4 Add Lock Token ...................................................................................................... 18

6. Connector Configuration .............................................................................................. 19

6.1 Introduction ............................................................................................................. 19

6.2 Establishing a Connection to the Standard Repository of the ECM Store ................. 19

6.3 Configuring a Repository......................................................................................... 20

6.4 Establishing a Connection to a Custom Repository of the ECM Store ...................... 23

7. References ..................................................................................................................... 23

1. Business Scenario

This guide will show you how to use the Java API of the Enterprise Content Management

Infrastructure (ECMI) of SAP NetWeaver to consume content and services within your business

application. As part of this guide, you will also learn how to set up the development environment and

how to use the most important API calls.

2. Background Information

Enterprise Content Management (ECM) is the strategies, methods and tools used to capture, manage,

store, preserve, and deliver content and documents related to organizational processes. ECM tools

and strategies allow the management of an organization's unstructured information, wherever that

information exists (source: AIIM).

The ECM Infrastructure (ECMI) of SAP NetWeaver offers an abstraction and service layer to consume

various ECM services by different service providers via a harmonized Java API. These ECM services

are provided by SAP as well as partners via a service provider interface (SPI) which is not in focus of

this How-To Guide. The current Java documentation for the Java API and SPI can be found on SDN:

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/50daac37-f929-2d10-2d8f-cd122ccf6e6d

These are ECMI interfaces and classes for accessing content repositories in a generic way,

independent of the underlying content repository implementation. Interfaces in this package are

implemented by ECMI itself and don’t need to be implemented by applications. The API package is

self contained, with no dependencies other than the JDK 1.5 libraries.


3. Step-by-Step Procedure

3.1 Setting up the development environment

To get started with development you need a SAP NetWeaver Developer Studio 7.2 or higher. The

required software component ECM-CORE will be installed within this Developer Studio version.

3.1.1 Create a new Development Component (DC) for your

project

1. Create a new DC (for example a Java Development Component).:

2. In the Dependencies Tab of that DC click 'Add', select the 'ECM-CORE' SC and choose the

DC 'tc/ecm'. Click Next.

3. If you wish to work only with the API or SPI disable the appropriate dependency. Click finish.

4. Select 'tc/ecm' and check the 'Deploy Time' and 'Runtime' checkboxes in the Dependency

Details view.

5. Now you can switch to the Java perspective and should have access to the ECM API/SPI

interfaces (API and SPI libraries should be present under the 'Required Development

Components').

3.2 Introduction to the ECMI Java API

The entry point of accessing an ECM system is to connect an existing ECM repository. For your

convenience SAP delivers a default store as part of the ECMI installation. This default store, called

ECM Store, stores the content on the file system and the metadata in the database of the J2EE

engine.

3.2.1 Login to the ECM Store

To connect to the store you have to use the following method in the Application interface:

Ecm ecm = (Ecm) new InitialContext().lookup(Ecm.JNDI_LOOKUP_KEY);

Application app = ecm.connect("","");

Repository repository =

app.getRepository(EcmName.get("", "default")) ;

After the JNDI lookup was successfully finished you can login to the ECM Store

Session session = repository.login();

If you have got a valid session object, you can retrieve the repositories hierarchy by calling the root

node.

Node root = session.getWorkspace().getNode(Path.getPath("/"));

3.2.2 Files, folders and external links in the repository

If you have accessed the root node of the repository, you could traverse the repositories hierarchy with

the Java API:

List<Node> children = ((Folder) root).getChildren();

for (Node child:children) {

if (child instanceof Folder) { }

if (child instanceof File) { }

if (child instanceof ExternalLink) { }

}

There are three types of objects you can check for:

1. Folder – Represents a folder bound to the session it was obtained from. The object provides

methods for querying and manipulating a folder's properties and children.

2. File - Represents a file bound to the session it was obtained from. The object provides

methods for querying and manipulating a file's content.

3. External Link - Represents an external link bound to the session it was obtained from. The

object provides methods for querying and manipulating the URI stored at the external link.

3.2.2.1 Folders – navigation nodes and collections for all node types

Within folders you can store files, external links and folder objects. The folder is the collection object of

the ECMI. It also can contain properties, a defined set of metadata bound to every object. Folder

cannot contain content.

Folder folder = (Folder)

session.getWorkspace().getNode(Path.getPath("/folder1_1"));

String newContent = “xy”;

ByteArrayInputStream byteArrayInputStream =

new ByteArrayInputStream(newContent.getBytes());

File file = folder.createFile("myFile", byteArrayInputStream);

ExternalLink externalLink =

folder.createExternalLink("myLink", null, new URI("http://www.sap.com"));

Folder subfolder = folder.createFolder("myFolder", null);

Getting all children elements of a single folder you can traverse the hierachry like done on teh root

level.

List<Node> children = folder.getChildren();


if (child instanceof Folder) { }

if (child instanceof File) { }

if (child instanceof ExternalLink) { }

}

3.2.2.2 Files – the content containing objects

The content of a file could be accessed via Java’s Stream APIs. The call can be directly performed on

the retrieved Content object.

File file = folder.createFile("myFile", null);

Content c = file.getContent();

BufferedInputStream bufin = new BufferedInputStream(c.getStream());

The wrapped buffered stream could be processed as usual in Java stream handling.

Alternatively the content of a file could be retrieved directly from the connected backend system if the

access to the content is URL-based.

Content c = file.getContent();

String contentURL = c.getContentURL();

To access the URL directly the connected repository must provide the URL in this method call.

3.2.2.3 External links – Content outside of ECMI

With the ExternalLink object you can access content which is not stored directly in the ECM

repositories. You could address all URI-based objects with the external Link object from within the

ECMI framework.

ExternalLink externalLink = folder.createExternalLink(…);

URI targetUri = externalLink.getTargetUri();

3.2.3 Accessing the metadata (properties) of ECM objects

A Property object represents the smallest granularity of content storage. A property consists of a name

and a value, or in the case of multi-value properties, a set of values all of the same type.

File file = ...

Property prop = file.getProperty(

EcmName.get(

EcmConsts.SAP_ECM_NAMESPACE,

EcmConsts.PROP_DISPLAYNAME)

);

System.out.println(prop.getValue().getString());

3.2.4 Basic functions – Copy, move and delete

Every ECM object can copy itself to another location. The target location must exist, otherwise the

copy will fail:

File file = ...;

file.copy(Path.getPath("/folder2_1/"), true);

Moving a file is quite the same call, except the method name

File file = ...;

file.move(Path.getPath("/folder2_1/"), true);

Every object could delete itselt by calling the deleteNode() method

File file = ...;

file.deleteNode();

3.3 A first ECM Application – An ECM Navigation

Cloud

A first simple application should demonstrate some of the ECMI Java API calls in an application

context. The example is based on a Java Servlet and renders a tag cloud based on the repository

structure of the ECM Store. Navigation to the hierarchy is simply realized with href links.

Keep in mind that this example will only work if the underlaying repository is supporting hierarchies.

The application renders links to ECM folders and make them clickable and navigateable.

3.3.1 Create the Java Web Module

1. Create a new Java Web Module projects

2. Create an Enterprise Application project

3. Assign the formerly created web module to this Enterprise Application module

4. Add a new servlet object to the web module project

5. Specify the class name and finalize

3.3.2 Implement the application logic

The first step is to get the specified start folder from an URI parameter, which is used as initial

navigation target by the servlet.

String rootID = request.getParameter("root");

if (rootID==null) rootID = new String(new char[] {Path.PATH_SEPARATOR} );

If no navigation target (rootID) is specified the path separator sign is taken, which represents the

root folder of the repository.

In the following step we will login to our ECM Store repository.

Ecm ecm = (Ecm) new InitialContext().lookup(Ecm.JNDI_LOOKUP_KEY);

Application app = ecm.connect("","");

Repository repository =

app.getRepository(EcmName.get("", "DS")) ;

Session session = repository.login();

Now you have to fetch all the children elements from the current folder, or root, which should be

rendered.

Node root = session.getWorkspace().getNode(Path.getPath(rootID));

List<Node> children = ((Folder) root).getChildren();

To build up a list with href links you have to iterate over all retrieved children elements.


if (child instanceof Folder) {

The links a build up manually in a StringBuffer object

StringBuffer fileList = new StringBuffer();

int subitems = ((Folder)child).getChildren().size();

content.append("<a href=\"");

content.append(request.getRequestURI());

content.append("?root=");

content.append(rootID);

content.append(child.getName());

content.append(Path.PATH_SEPARATOR);

content.append("\" style=\"font-size: ");

content.append(Math.min(subitems+10, 72));

content.append("pt;\">");

content.append(child.getName());

content.append("</a>");

content.append(CRLF);

The complete application can be found the attched EAR file.

3.3.3 Deploy and run the example application

1. Switch to the Development Infrastructure perspective in the SAP NetWeaver Developer Studio

and open the former created DC component. Select the Build… command in the popup menu

to create the deployable unit (EAR archive)

2. Deploy the created EAR archive

3. Go to the SAP Management console and navigate to AS Java Aliases.

4. Look for the deployed application and launch the application in a browser (should appear

automatically)

4. Restricting Access to Files and Folders

The ECMI Java API provides the possibility to restrict the access to files and folders for particular

principals (users, groups or roles) via Access Control Lists (ACLs) if the currently used repository

supports this feature. In the following we present the general concepts together with some examples.

For all examples we assume that the ECM default repository is used. Other repositories might behave

a little bit different with respect to ACLs. You will find more details in the ECMI Java API

documentation (Javadoc):


4.1 Restricting Access to a File

In the next example we restrict the access to a file with the following path “/test/file.txt”. Thereby we

want to allow the current user full access to the resource, i.e. allowing him all operations on the

resource like reading and modifying the content and properties or even deleting the file. For all users

which are member of a particular group we want to allow read access, i.e. they are allowed to access

the file, its content and properties but are not allowed to modify them.

First of all you have to fetch the current user as well as the group mentioned above. How to do this it

out of the scope of this tutorial.

In the next step you have to create an ACL defining the access rules described above. An ACL is a list

of Access Control Entries, whereby every Access Control Entry (ACE) grants a particular access right

or privilege to a principal. The ACL constructed in the following gives the current user all privileges and

all users of “group1” read access.

Finally you have to assign the ACL to the file. Therefore we access the file and convert it into an

AclControllable which provides the interface to maintain ACLs at nodes. At the AclControllable we

could set the ACL and thereby restricting the access to the file as described above. To modify the ACL

of a node the principal which has fetched the node must have full access to it.

IUser currentUser = ...;

IGroup group1 = ...;

List<AccessControlEntry> accessControlList

= new ArrayList<AccessControlEntry>();

AccessControlEntry accessControlEntry = new AccessControlEntry(

currentUser, StandardPrivilegeSet01.ALL_PRIVILEGE);

accessControlList.add(ace);

accessControlEntry = new AccessControlEntry(group1,

StandardPrivilegeSet01.READ_PRIVILEGE);

accessControlList.add(ace);


The propagation level is only relevant when setting ACLs at a folder and the access restrictions should

be propagated to its descendants. If it is set to 0 the ACL is set only for the current node. Also the

parameter “suppressErrors” is more relevant for folders. Setting it on “true” will not result in an

exception if e.g. the user setting the ACL does not have this right at some descendant of the current

folder.

If a principal tries to execute an operation on a node, for which he does not have the rights, an

AccessDeniedException is thrown.

4.2 Privileges

In the Chapter before, ACEs were created using the class StandartPrivilegeSet01. This class contains constants for all privileges currently supported by the ECM standard repository. These privileges and some of their properties are:

READ_PRIVILEGE: Allows fetching the node, its content and properties and in case of a folder also its children.

READ_WRITE_PRIVILEGE: Covers all privileges of READ but allows modifying the content and the properties of the node. In case of a folder new children could be added.

ALL_PRIVILEGE: Covers all privileges of READ_WRITE but allows modifying the ACL settings and deleting the node.

When a new ECM repository is configured, also an administration principal is defined, having always full access to all nodes of the repository without considering some ACL settings. Initially other principals have no permissions. The administration principal could be used to grant other principals access to particular parts of the repository, e.g. he could create a new top level folder and assigning an ACL to it. All principals having privileges granted by this ACL could now work in that folder according to the permissions they have. If a principal is allowed to create a new node under a folder, the ACL of this folder is copied to the new node. If this ACL of the new node does not contain the ALL_PRIVILEGE ACE for the user such an entry is added automatically. The ACL currently set at a node could be fetched via:

Node file = session.getWorkspace()

.getNode(Path.getPath("/test/file.txt"));

AclControllable aclControllable = file.getAsAclControllable();

int propagationLevel = 0;

boolean suppressErrors = false;

aclControllable.setAcl(accessControlList,

propagationLevel, suppressErrors);

AclControllable aclControllable = ...;

Iterator<AccessControlEntry> aces =

aclControllable.getAccessControlEntries();

4.3 Other ACL related Methods

It is possible to set ACLs for folders and specifying if the ACL should also be set to all descendants of the folder by specifying a propagation level with -1 (0 means that the ACL is set only at the current node): Furthermore you might add some ACEs to already existing ones:

You might also remove some ACEs from existing ACLs:

4.4 Checking Privileges

It is possible to check if the user who has fetched a node has particular privileges at it. The following coding shows how to check if the user has READ_WRITE_PRIVILEGE at a node. Of course the result of this test is also true if he has full control to this node.

Folder folder = ...;

AclControllable aclControllable = folder.getAsAclControllable();

Iterator<AccessControlEntry> aces = ...;

int propagationLevel = -1;

aclControllable.setAcl(aces, propagationLevel, true);

Node node = ...;

AclControllable aclControllable = node.getAsAclControllable();



aclControllable.addAccessControlEntries(aces,

propagationLevel, true);

Node node = ...;

AclControllable aclControllable = node.getAsAclControllable();



aclControllable.removeAccessControlEntries(aces,

propagationLevel, true);

The PrivilegeCheckable interface possesses an additional method providing the privileges of the

current user at the resource.

5. Locking

5.1 General

Locking as supported by the ECM standard repository mainly allows a principal to work on a node

exclusively, i.e. when a principal (user, group or role) has locked a node no one else is able to modify

it in the meantime. On the other hand all other principals are still allowed to read its content and

properties.

Other repositories might support more complicated locking scenarios but here we restrict our focus on

what the ECM reference store provides.

In the ECMI Locking concept every lock of a node might be owned by a session. The session through

which a principal places a lock on a node is automatically the owning session of that lock. The node is

called the carrier of the lock. The user attached to the session creating the lock is called the lock user.

Every lock has a corresponding lock token which is stable for the life time of the lock. The lock token is

some string created automatically by the repository during lock creation. A session holding the lock

token is the owning session of the lock. That means that the session through which a user places a

lock on a node automatically holds the corresponding lock token.

Only an owning session of a lock can execute the operations protected by the lock if there are no

other access restrictions preventing this. For the ECM store, only the owning session is allowed to

modify, delete or unlock the node.

In the following we will show how to use locking. Thereby we restrict the discussion on locking using

ECMI together with the ECM reference store. When a new ECM repository is configured, also an

administration principal is defined, which has always full access to all nodes without considering

existing locks. This principal is also always possible to remove any existing lock.

5.2 Lock a node

In the following we want to show how to lock a node. In the first step you have to get the node as a

Lockable, which provides the locking API:

Node myNode =

session.getWorkspace().getNode(Path.getPath("/folder1_1/myFile"));

Lockable lockableNode = myNode.getAsLockable();

Node node = ...;

PrivilegeCheckable checkable = node.getAsPrivilegeCheckable();

List<Privilege> privileges = new LinkedList<Privilege>();

privileges.add(StandardPrivilegeSet01.READ_WRITE_PRIVILEGE);

boolean test = checkable.hasPrivileges(privileges);

The next step is to define the properties of the lock which define the characteristics of the lock. The

ECM standard repository supports

deep and shallow locks. Shallow locks only lock the current node. Deep locks also lock all

descendants of a folder.

exclusive locks, i.e. only one lock could be created at a node at the same time.

write locks, i.e. only the session owning the lock is allowed to modify the node. All others are

only allowed to read the properties and content in the meantime.

timeout of a lock, which specifies when the lock expires. This time is specified in milliseconds.

A timeout of LockProperties.TIMEOUT_INFINITE means, that the lock never expires

automatically.

The following coding shows how to define the lock properties and lock the node.

LockProperties lockProperties = new LockProperties(LockType.WRITE,

LockScope.EXCLUSIVE, LockDepth.SHALLOW, 10000);

Lock lock = lockableNode.lock(lockProperties);

After this operation, the lock token of the lock is automatically added to the current session object and

modifications on that node are only possible via that session. We will describe later how other

sessions might also become able to modify a locked node.

5.3 Unlock a node

To unlock a node the first step is to get the node as a Lockable and then to unlock it:

Node myNode =



lockableNode.unlock();

Please note that the unlock operation will only work if the current session is holding the lock token of

the lock of the node.

5.4 Add Lock Token

If a locked node should be modified or unlocked via a session this session has to hold the lock token

of the lock. If the lock was created via the session itself, the lock token was added automatically such

that it already holds the lock token. If not, the lock token has to be fetched from somewhere else e.g.

from the locked node and added to the session.

To get the lock token from the node you have to get the node as a Lockable first:

Node myNode =



In the next step you have to fetch the locks which are carried by the current node and add their lock

token to the session object. Of course for the ECM reference store there could be at most one lock at

a node.

List<Lock> locks = lockableNode.getLocks();

Iterator<Lock> locksIt = locks.iterator();

while (locksIt.hasNext()) {

Lock lock = (Lock) locksIt.next();

String lockToken = lock.getLockToken();

session.addLockToken(lockToken);

}

For the ECM standard store only the principal who has created a lock is able to fetch the corresponding lock token from the node. It is also only possible to add such a lock token to sessions created for this principal.

6. Connector Configuration

6.1 Introduction

As part of the ECM infrastructure (ECMI) SAP delivers a store implementation called the ECM store. In

this store there is a default repository, the ECM standard repository, which can be used out of the box

after deployment. The access to the repository is established through a connector which is a JCA

(Java EE Connector Architecture) compliant resource adapter. It can be configured in the SAP

NetWeaver Administrator.

JCA is a Java-based technology solution for connecting application servers and enterprise information

systems (EIS) as part of enterprise application integration (EAI) solutions. It defines a standard for

connecting a compliant application server to an EIS. And defines a standard set of system-level

contracts between the JEE application server and a resource adapter. More information to JCA can be

found in the JCA specification.

6.2 Establishing a Connection to the Standard

Repository of the ECM Store

To connect to the ECM standard repository you simply use the following code:

InitialContext context = new InitialContext();

ECM ecm = (Ecm) context.lookup(Ecm.JNDI_LOOKUP_KEY);

Application application = ecm.connect("", "appname");

Repository repository = application.getRepository(EcmName.get("",

"default"));

6.3 Configuring a Repository

It is possible to configure an existing repository and/or create new repositories in the ECM Store

through the SAP NetWeaver Administrator. To create a new repository just perform the following

steps:

1. Login to SAP NetWeaver Administrator and go to Configuration Management Infrastructure

Application Resources.

2. Select the JCA Resources in the “Show” combo box to display the deployed resource

adapters. The SAPContentStoreJava resource adapter should be present in the Resource List

view. If not make sure that the ECM Store is deployed and running.

Select the SAPContentStoreJava. In the Resource Details View under the Dependent JCA

Connection Factories tab a resource entry with name ecm/default will be displayed which is

the connection factory to access the standard repository in the ECM Store.

3. To create a new repository you have to create a new connection factory. Select the

ecm/default entry and click on “Copy and Add New JCA Connection Factory”. A new window

appears where you can specify a JNDI Name for the connection factory. It is mandatory that

the name starts with ecm/. For example use ecm/myrepository.

4. Choose the Configuration Properties tab to display the configurable properties for the ECM

Store. Here you can change the following parameters:

- RepositoryDbId – this is the name of the root node in database and the name of the

folder where all content will be stored in SAP NetWeaver. The present value “default” means

that the JNDI name value ecm/myrepository will be used for the name generation of the folder.

Note: this parameter value must be unique! If not it is possible that two JCA Connection

Factory entries map to the same repository which should be avoided!

- ContentStorePath – the path on the file system where the content will be stored. If the

place does not exist the connector will try to create it.

- SuperUserRole – the unique ID of the principle (could be any of user, role or group) who

is has full access to the content of the repository and is allowed to modify ACLs, locks etc.

It is recommended that you set the RepositoryDbId to a unique name like

“mycontentrepository” for example and leave the ContentStorePath parameter at the default

value. You can modify the SuperUserRole property if you desire.

Additionally you can customize other parameters like the Connection Pooling parameters

(connection pool size, timeout values etc.). For more information about these parameters see

the JCA specification. For now leave them at their default values.

Finally click on Save.

5. Now you have two connection factories defined for the SAPContentStoreJava resource

adapter.

To delete an existing connection factory simply select the corresponding entry and click on Delete

JCA Connection Factory.

To modify an existing entry select it and click on “JCA Connection Factory Details”. It is now

possible to adjust the parameters as described above. Note: The JNDI name of an existing

connection factory cannot be modified.

Note: If there is already content in the store for the current entry you should not modify the

RepositoryDbId and ContentStorePath parameters or you won’t be able to access your content.

Finally click on Save.

6.4 Establishing a Connection to a Custom

Repository of the ECM Store

To connect to the repository through the newly defined connection factory (see previous step) use the

following code of the ECMI API:

InitialContext context = new InitialContext();

ECM ecm = (Ecm) context.lookup(Ecm.JNDI_LOOKUP_KEY);

Application application = ecm.connect("", "appname");

Repository repository = application.getRepository(EcmName.get("",

"myrepository"));

As you might notice the code is nearly identical to the code above describing the connection to the

standerd repository. The only difference is that name of the connection factory (without the leading

/ecm) is used to fetch the repository.

Note: Currently the namespace for the ECMName in application.getRepository(...) is ignored. Only the

name value will be used for looking up the repository. In future ECMI versions the namespace will also

be supported.

If the repository does not exist a new one will be created in the ECM Store.

7. References

ECMI Java API – Javadoc:


Java EE Connector Architecture (JCA):

http://java.sun.com/j2ee/connector/


http://java.sun.com/j2ee/connector/

Get Started Developing with the Java API of the ECM ... · PDF fileHow SAP NetWeaver -To Guide...

Documents

Transcript of Get Started Developing with the Java API of the ECM ... · PDF fileHow SAP NetWeaver -To Guide...