The UCPM API is modeled into a set of services APIs, which are API calls that communicate with the content server.
This chapter contains the following sections:
Note:
Refer to Oracle Fusion Middleware Content Integration Suite (CIS) Java API Reference for information on the Class/Interface, Field, and Method descriptions.The UCPM API is available on the CISApplication class via the getUCPMAPI () method. The getUCPMAPI () method returns a reference to the IUCPMAPI object, allowing access to all UCPM API objects. The public interface IUCPMAPI is the locator for the SCS, SIS, and CIS API objects. The SCS API is available via getActiveAPI (), which returns a reference to the SCSActiveAPI object.
The fully qualified method name is:
CISApplication.getUCPMAPI ().getActiveAPI ()
The SCS API comprises the following:
ISCSSearchAPI: This is the command API implementation of the search commands.
ISCSFileAPI: Deals with the retrieval of files, and the dynamic conversions of files, from the content server.
ISCSWorkflowAPI: Deals with the workflow commands such as approval and rejection, viewing a user's workflow queue, and interacting with the content server workflow engine.
SCS Document APIs (ISCSDocumentCheckinAPI and ISCSDocumentCheckoutAPI), which deal with active content in the content server, including checking in and out of content, content information, and deletion of content.
Various APIs for the implementation of the administrative commands, component commands, and so on.
The interface ICommandFacade is the entry point into the command interface. It allows for interaction with the command layer, including command retrieval, registration, and execution. Commands are referenced by name, where a name can be any string. A name consisting of the dot character (".") will be treated in a hierarchy, where the first segment is the top-level category, and the next segment is the second-level category, and so on. Commands can either be retrieved by their full command name or by browsing all available commands.
The fully qualified class name is
com.stellent.command.ICommandFacade
Example using ISCSDocumentCheckinCommandAPI:
ISCSDocumentCheckinCommandAPI commandAPI =
(ISCSDocumentCheckinCommandAPI)m_commandFacade.
getCommandAPI ("document.checkin");
The SCS API is responsible for formulating requests to the content server. SCS API calls translate into one or more IDC Service (Content Server Service) calls.
This section contains the following topics:
The ISCSObject is the base interface for all objects in the SCS API. It inherits from ICISObject and adds some specific functionality relative to the content server objects. It allows access to the ISCSServerResponse object that created the object, and it also allows access to a collection of properties that have been modified since the object was initialized via the getModifiedProperties () method.
The ICISObject class name is new for UCPM 8.0.0 API.
ISCSObject objects have the concept of native property names. Specifically, properties that are available on ISCSObject are available by two different names: the Java property name and the content server native name. For example, to get the title of a ISCSContent item, the following three methods are equal:
String title = content.getTitle ();
title = content.getProperty ("title").getValue ().getStringValue ();
title = content.getProperty ("dDocTitle").getValue ().getStringValue ();
The content server supports a metadata model that can be extended. ISCSObject objects can have more properties than those exposed via the getProperty () methods. The ISCSObject implementations expose the most common properties, but other properties, such as the extended metadata, are only available via the getProperty () method. Also, the getProperties () method will list all the properties on the object, including properties without a corresponding getter or setter method.
for (Iterator it = content.getProperties ().iterator (); it.hasNext (); ) {
ISCSProperty property = (ISCSProperty)it.next ();
ISCSPropertyDescriptor descriptor = property.getActiveDescriptor ();
if (descriptor.isBeanProperty ()) {
System.out.println ("Property is available via get or set: " +
property.getDescriptor().getName ());
} else {
System.out.println ("Property is a hidden or extended property: " +
property.getDescriptor().getName ());
}
System.out.println ("Native property name: " + descriptor.getNativeName ());
}
The properties returned from ISCSObject implement the ISCSProperty interface, which adds the getActiveDescriptor () method. The ISCSPropertyDescriptor adds the beanProperty and nativeName properties to the available properties on an item.
The beanProperty property determines if the current property object has an available getter or setter method; if the property is false, this property object is available only via the getProperty () method.
The nativeName property returns the content server property name for the given property.
Date fields in the SCS API are handled as Java Date objects in Coordinated Universal Time (UTC time). All dates passed into the various properties of ISCSObject must be in UTC time. All date objects returned from the SCS API are in UTC time and need to be converted into the appropriate time zone for the particular application.
Date releaseDate = content.getReleaseDate ();
// convert from UTC time to Pacific Time Zone
Calendar calendar = Calendar.getInstance ();
calendar.setTime (releaseDate);
calendar.setTimeZone (TimeZone.getTimeZone ("America/Los_Angeles"));
// use calendar to display date...
File streams to and from the content server have changed. In an effort to keep with the interface-only approach to the CIS APIs, all streams are sent via the ICISTransferStream interface. The interface represents the actual physical stream object and additionally some metadata, including filename, content length and mime-type. Since the ICISTransferStream is an interface, it cannot extend InputStream directly. Therefore, when using this object, you must first obtain the stream via a call to ICISTransferStream.getStream() and then manipulate the stream appropriately.
Some commands that in previous versions would return an InputStream now return ICISTransferStream objects. For example, if calling getFile() in the FileAPI, to access the stream from the content server, your code would look like:
ICISTransferStream transferStream = fileAPI.getFile (context, documentID); InputStream inputStream = transferStream.getInputStream();
The implementation of ICISTransferStream contains all the necessary plumbing to transfer the stream to and from the command client to command server. Since InputStream objects are not directly serializable, it does some extra work to put streams into places where the server can access them. All of the logic is hidden from the user of the API.
The stream instance can be obtained from the root IUCPMAPI interface using the method createTransferStream. That returns an empty instance of the stream container, which you can then use the accessors methods to set the stream properties. For example, below we create a transfer stream and point it at a local file:
// create the stream implementation
ICISTransferStream transferStream = ucpmAPI.createTransferStream ();
// point it at a file
transferStream.setFile (new File ("mytestdoc.doc"));
If you had a stream in memory already rather than a file handle, and you wanted to check in the content in that stream into the content server, you would need to specify all of the attributes for the stream such as a filename, content type, and the length of the stream.
ICISTransferStream transferStream = ucpmAPI.createTransferStream ();
transferStream.setFileName ("sample.txt");
transferStream.setInputStream (inputStream);
transferStream.setContentType ("text/plain");
transferStream.setContentLength (length);
checkinAPI.checkinFileStream (context, content, transferStream);
The CIS 8.0.0 API provides a new object, ISCSServerBinder, which is the root object used for all communication to and from the content server. The ISCSServerBinder object encapsulates a message both to and from the content server. It is a collection of properties, result sets, files, option lists and other specific type of information needed by the content server.
All API calls into the content server will create an instance of the ISCSServerBinder. Each API call, for example ISCSSearchAPI.search(), will use the supplied ISCSObject parameters to populate a binder and possibly add in other particular information. Likewise, all responses from the content server that are not streams are ISCSServerResponse objects which extend ISCSServerBinder.
As all ISCSObjects are collections of arbitrary metadata, the ISCSServerBinder is a collection of a number of objects metadata contained within one object. A particular ISCSServerBinder might contain the metadata for a content server query (see ISCSSearchQuery), metadata concerning a piece of content, and a list of objects dealing with user data. As each ISCSObject contains the particular metadata for its object, the ISCSServerBinder is responsible for the metadata of many objects.
As ISCSServerBinder extends the core ISCSObject interface, it has the ability to get and set arbitrary properties via the getProperty and setProperty methods. These arbitrary properties are usually where arguments for a particular content server are placed. They can be added directly, via the setProperty method as shown in the following code example.
// create an empty binder
ISCSServerBinder binder =
(ISCSServerBinder)getUCPMAPI ().createObject (ISCSServerBinder.class);
// set some properties
binder.setProperty ("dDocTitle", "test");
binder.setProperty ("dSecurityGroup", "Public");
Alternatively, properties can be set using the mergeObject functionality available on the ISCSObject interface. The following example shows creating another object, setting some properties on that object, and then using merge to put those properties into the server binder.
// create an empty content item
ISCSContent content = (ISCSContent)getUCPMAPI ().createObject (ISCSContent.class);
// set some properties
content.setTitle ("test");
content.setSecurityGroup ("Public");
// merge into binder; this copies all the properties from content into the binder
binder.mergeObject (content);
The above two examples are identical: they both result in setting the content item title (dDocTitle) and security group (dSecurityGroup) in the ISCSServerBinder object. However, by using the second method, we abstract ourselves from having to deal with the specifics of content server naming. The ISCSContent object handles the mapping of standard Java properties into content server metadata.
A result set represents a collection of rows returned from a content server query. This is exposed in ISCSServerBinder via the getResultSet and setResultSet methods. A result set in the SCS API is then exposed as a homogeneous list, containing a type of object the represents a single row of the result set. Many items returned from content server queries come back as result sets. As all the result sets are lists of ISCSObject objects, the items from the result sets can be used in other calls. For example, look at the following code snippet where a search is executed and the first item then has its contents updated:
// create an simple query
ISCSSearchQuery query =
(ISCSSearchQuery)getUCPMAPI ().createObject (ISCSSearchQuery.class):
query.setQueryText ("dDocName <substring> 'test' ");
// execute a search
ISCSSearchResponse response =
getUCPMAPI ().getActiveAPI ().getSearchAPI ().search (context, query);
// search results come back as a result set of ISCSSearchResult items
ISCSSearchResult result = (ISCSSearchResult)response.getResults ().get (0);
// change the title and check it in
result.setTitle ("new title");
getUCPMAPI ().getActiveAPI ().getDocumentUpdateAPI ().
updateInfo (context, result);
The ISCSServerBinder allows files to be sent to the content server via the addFile method. This method takes an ICISTransferStream. The resulting file is sent to the content server, along with the binder, during the request. Adding a file is similar to adding a property:
// create an empty stream
ICISTransferStream stream = getUCPMAPI ().createTransferStream ();
// point the stream at a local file
stream.setFile (new File ("testfile.txt"));
// add the stream to the binder
serverBinder.addStream ("myFile", stream);
When the above binder is sent to the content server, the stream will be transferred along with the binder. Inside the content server, the stream will be available under the "myFile" key which was specified when adding the stream to the binder.
Each ISCSObject in the SCS API has an object that holds the data in a low-level format compatible with Oracle Content Server. This object, referred to as a data object, is used by all ISCSObject implementations. This implies that any ISCSObject can be mutated to any other type of ISCSObject. There are two methods that expose this functionality: the castObject and copyObject methods available on the ISCSObject interface.
Both methods take in a single parameter: a class type representing the type of object that should be created. A call to castObject will result in the creation of a new object that points at the same backing data of the object it was invoked against. This implies that changes to the original object will be reflected in the object returned from the castObject call as well. A call to copyObject will result in a copy of the backing data being made, allowing the newly created object to act independently from the original object.
For example, imagine there is a custom content server service called "MY_DOC_INFO" which is similar to the standard "DOC_INFO" but it does some extra business logic processing. However, the returned binder from the "MY_DOC_INFO" call is very close to the "DOC_INFO" call. Since there is no explicit API call in the SCS API to call this "MY_DOC_INFO" service, we have to use the generic executeIDCService call. But we can use the castObject method to change the return type into something more user friendly:
// build our custom call
ISCSServerBinder binder =
(ISCSServerBinder)getUCPMAPI ().createObject (ISCSServerBinder.class);
binder.setService ("MY_DOC_INFO");
// create a document ID and add it to the binder
ISCSDocumentID documentID =
(ISCSDocumentID)getUCPMAPI ().createObject (ISCSDocumentID.class);
documentID.setDocumentID ("12345");
binder.mergeObject (documentID);
// execute the call
ISCSServerResponse response =
(ISCSServerResponse)getUCPMAPI ().getAdministrativeAPI ().
executeIDCService (context, binder);
// use the cast to change it to a ISCSDocumentInformationResponse
ISCSDocumentInformationResponse infoResponse =
(ISCSDocumentInformationResponse)response.
castObject (ISCSDocumentInformationResponse.class);
// use the info response as usual
System.out.println ("Title: " + infoResponse.getDocNode ().getTitle ());
As mentioned above, the castObject call links the two objects by sharing the same backing data. In the above example, any changes made to the response object would be reflected in the infoResponse object as well:
// set a property on the response
response.setProperty ("customProperty", "customValue");
// value is then available in the infoResponse object
String value = infoResponse.getPropertyAsString ("customProperty");
If copyObject was called instead, the response and infoResponse would be independent of each other. The castObject creates a smaller memory footprint than copyObject, since the result from a castObject call does not create a new backing data object.
The result of a call to the SCS API is usually an ISCSServerResponse object. The ISCSServerReponse is the base interface for all the response objects. It encapsulates the response from the content server for the last request. Most methods have specific implementations of this interface, which provide properties that are specific to those responses. See the JavaDocs for the specific response objects, and the properties available to each.
In the current release, some calls that previously returned references to an InputStream now return a ICISTransferStream object instead. See Interface ISCSRequestModifier on how to use the new transfer stream interface.
All requests to the content server via the SCS API result in the creation of an ISCSServerBinder object. In certain situations, it becomes necessary to change the binder contents for a given API call to match the requirements of a specific content server. The ISCSRequestModifier interface is designed for this very purpose: to augment a call to the content server with custom modifications.
All APIs in the SCS API have a corresponding method that takes as the first parameter an ISCSRequestModifier object. Look at the API for ISCSSearchAPI:
/**
* Command the implements searching against the content server.
* @param SCSContext the context object representing the current user
* @param searchQuery the content server query object
*/
public com.stellent.cis.client.api.scs.search.
ISCSSearchResponse search (com.stellent.cis.client.api.scs.context.
ISCSContext SCSContext,
com.stellent.cis.client.api.scs.search.ISCSSearchQuery searchQuery)
throws com.stellent.cis.client.command.CommandException;
/**
* Command the implements searching against the content server.
* @param requestModifier modify the request
* @param SCSContext the context object representing the current user
* @param searchQuery the content server query object
* @see com.stellent.cis.server.api.scs.commands.search.SearchCommand
*/
public com.stellent.cis.client.api.scs.search.
ISCSSearchResponse search (com.stellent.cis.client.api.scs.
ISCSRequestModifier requestModifier, com.stellent.cis.client.api.scs.context.
ISCSContext SCSContext, com.stellent.cis.client.api.scs.search.I
SCSSearchQuery searchQuery)
throws com.stellent.cis.client.command.CommandException;
The second API takes all the parameters of the first, with the additional ISCSRequestModifier argument. The standard Search API, and all its logic, can be used and custom logic added. For example, imagine a custom component installed on the content server that will do some extra processing if it find the "myCustomProperty" property set during a search query. To do this with CIS, we can use the ISCSRequestModifier to change the binder as follows:
// build a search query
ISCSSearchQuery query =
(ISCSSearchQuery)getUCPMAPI ().createObject (ISCSSearchQuery.class);
query.setQueryText ("dDocName <substring> `test`");
// build a request modifier
ISCSRequestModifier modifier =
(ISCSRequestModifier)getUCPMAPI ().createObject (ISCSRequestModifier.class);
// access the binder off the modifier and add in our custom data
modifer.getServerBinder().setProperty ("myCustomProperty", "customValue");
// execute the search as normal
getUCPMAPI ().getActiveAPI ().getSearchAPI ().search (modifier, context, query);
Now the binder we modified will be used during the search call. Our custom property value will get sent along with the standard search call. This same method can be used to set any properties, add files, set result sets or even override which service call is being made on the content server.
The SCS API requires that a number of servlets be available to the system while operating in a J2EE/Web environment and running in server mode.
This section contains the following topics:
This table lists the servlet names and the appropriate configuration information needed in the web.xml file for a given web application:
| Fully Qualified Name | Mapping | Description |
|---|---|---|
| SCSFileDownloadServlet | /getfile | Allows clients to retrieve files from the content server. |
| SCSCommandClientServlet | /scscommandclient | Publishes the CIS server configuration information for CIS clients. |
| SCSFileTransferServlet | /scsfiletransfer | Allows UCPM APIs to transfer files to a CIS client. |
| SCSInitialize | N/A | Initializes the CIS Application instance. Should be set as a LoadOnStartup servlet. |
| SCSDynamicConverterServlet | /getdynamicconversion/* | Executes a dynamic conversion and streams the result to the client. |
| SCSDynamicURLServlet | /scsdynamic/* | Retrieves dynamic files from the content server; used when rewriting the dynamically converted document URLs. |
This section provides a description of the parameters for these servlets:
This section does not specify any of the available security parameters, which are detailed in "Servlet Security". All calls made to the content server use the identity as specified in the servlet security section.
| Property | Required | Description |
|---|---|---|
| adapterName | true | The adapter name to query for the document. |
| dDocName | n/a | The content ID of the document to retrieve. |
| rendition | false | The content rendition; valid only when specifying the dDocName. |
| revisionSelection | false | The revisionSelection to use when selecting content; valid only when specifying the dDocName. |
| forceStream | false | If true, the contents are streamed from the content server via the GET_FILE call regardless of optimized file transfer settings for the adapter; defaults to false. |
| Property | Required | Description |
|---|---|---|
| adapterName | true | The adapter name to query for the document. |
| contentID | Either contentID or documentID is required. | The content ID (dDocName) of the document to retrieve. |
| documentID | n/a | The document ID (dID) of the document to retrieve. |
| rendition | false | The rendition of the document to retrieve; valid only if contentID is specified. |
| revisionSelectionMethod | false | The revisionSelectionMethod to use to select the document; valid only if contentID is specified. |
| viewFormat | false | The view format of the conversion (that is, Native or WebViewable). |
| useAlternate | false | If true, use the alternate file for conversion; default is false. |
| Property | Required | Description |
|---|---|---|
| adapterName | true | The adapter name to query for the document; not passed in as a parameter, but, rather, specified as the last segment on the URL:
/cis-server/scsdynamic/ <adaptername>?... |
| fileUrl | true | The relative path to the content server file to retrieve. |
All servlets, except for SISFileDownloadServlet and SCSInitializeServlet, make UCPM API calls and therefore must have a user context. By default, they will use the HttpServletRequest.getUserPrincipal() method to determine the user ID and pass that ID via the ISCSContext object to the UCPM API call. This behavior can be overridden by specifying a couple of initialization parameters to the servlet:
principalLookupAllowed: If set to TRUE, the servlet will look for a user ID in the configured scope. The default scope is session.
principalLookupScope: The scope of the lookup. Valid if principalLookupAllowed is TRUE. The defined scope will be used to call the getAttribute () method to discover the name of the current user; can be either request, session, or application. The default is session.
principalLookupName: The name of the scoped parameter that holds the user ID. Valid if principalLookupAllowed is TRUE. The default is principal.
getUserPrincipalEnabled: If set to FALSE, no call will be made to the HttpServletRequest.getUserPrincipal () method to determine the user ID. The default is TRUE.
principal: The default user ID if no user ID can be determined. The default is guest.
To determine the current user ID, the servlets will first check the status of the principalLookupAllowed flag. If TRUE, it looks up the name of the user by determining the scope as set by the parameter principalLookupScope. With the current scope, the getAttribute () method is called, using principalLookupName as the parameter. If it is unable to locate a principal, it then checks the status of the getUserPrincipalEnabled flag. If that flag is TRUE, it calls the HttpServletRequest.getUserPrincipal () method. If that returns null, it uses the default principal to execute the request.
Without any changes to the servlet, the default behavior is to check the HttpServletRequest.getUserPrincipal () method and then use the default, if necessary. The other checks on the request, session, and application are done only if specified in the init-param of the servlet definition in the web.xml file.
The ISCSFileAPI.getDynamicConversion() method performs a dynamic conversion of the given document (assuming the Dynamic Converter component is installed on the content server). The getDynamicConversion() call will also rewrite the returned URLs, so that they point back to the CIS servlets (as opposed to pointing directly to the content server) and display properly in the Web/Portal environment when they are rendered.
The rewritten URLs point back to SCSDynamicURLServlet, which then retrieves the item from the content server, via the SCS API, and streams it back to the client. The servlet determines the user ID for the context by the method described in "Servlet Security".
Since the servlet determines the user ID, the user who executed the getDynamicConversion() call might not have the same user ID as the user clicking a link on the rendered HTML. This would be the case if the HttpServletRequest.getUserPrincipal() user ID does not match the ISCSContext user ID
In that event, the SCSDynamicURLServlet can be directed to look for a user parameter on the session by customizing it via the methods described under "Servlet Security". Alternatively, SCSDynamicURLServlet can call the getDynamicConversion() and pass in an ISCSConvertedUrlInfo object that allows a user to optionally add parameters to the URL, which can then be used by your application to identify the context.
For example, if your application stored the current User ID in a session attribute named stellentPrincipal, you would modify the web.xml for the SCSDynamicURLServlet (and other servlets, as necessary) as follows:
<servlet>
<servlet-name>scsdynamic</servlet-name>
<servlet-class>com.stellent.web.servlets.SCSDynamicURLServlet</servlet-class>
<init-param>
<param-name>sessionPrincipalAllowed</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>sessionPrincipalName</param-name>
<param-value>stellentPrincipal</param-value>
</init-param>
</servlet>
The SCS Search, SCS File, SCS Document, and SCS Workflow APIs are discussed and sample code provided. These APIs perform task such as searching, checking in and out of content, and workflow approval and rejection.
It is assumed that you have initialized a CISApplication instance (referred to as m_cisApplication) and created a context object (referred to as m_context). Additional samples can be found in the SDK/Samples/CodeSamples/ directory.
This section contains the following topics:
The ISCSSearchAPI is the command API implementation of the search commands. You can use ISCSSearchAPI to search the content server using the following code:
// get a handle to the SCS Search API
ISCSSearchAPI searchAPI =
m_cisApplication.getUCPMAPI ().getActiveAPI ().getSearchAPI ();
ISCSSearchResponse searchResponse =
searchAPI.search (m_context, "dDocTitle <substring> 'HR'", 25);
// iterate all results
for (Iterator it = searchResponse.getResults ().iterator (); it.hasNext (); ) {
ISCSSearchResult searchResult = (ISCSSearchResult)it.next ();
// print out the title and author
System.out.println ("Found result: " + searchResult.getTitle () + " by " +
searchResult.getAuthor ());
}
The ISCSFileAPI deals with the retrieval of files, and the dynamic conversions of files, from the content server. A file can be retrieved simply by passing in the ID for the content. Alternatively, different versions of the file can be retrieved by using the optional ISCSFileInfo object to obtain references to the Web and Alternate versions of the file.
// get the SCS File API ISCSFileAPI fileAPI = m_cisApplication.getUCPMAPI ().getActiveAPI ().getFileAPI (); ICISTransferStream transferStream = fileAPI.getFile (m_context, content.getDocumentID ()); InputStream stream = transferStream.getInputStream(); // do something with the stream...
You can also use the _createFileInfo() method to get an ISCSFileInfo object. This object has several properties, which allow one to further select which rendition of a file to retrieve. The following sample uses the fileinfo object to get the Web Viewable rendition of a file. A similar process can be used to get the Alternate rendition.
// get the web viewable version of the file
ISCSFileInfo fileInfo =
(ISCSFileInfo) m_cisApplication.getUCPMAPI ().createObject(ISCSFileInfo.class);
fileInfo.setRendition ("Web");
// get the file
ICISTransferStream transferStream =
fileAPI.getFile (m_context, content.getDocumentID (), fileInfo);
InputStream stream = transferStream.getInputStream();
// do something with the stream...
The SCS File API can be used to generate HTML renditions of the content via the Dynamic Converter component of the content server (you must have the Dynamic Converter component installed).
In a similar fashion to the getFile () calls, you can either call getDynamicConversion () with an ID to retrieve the HTML conversion, or you can use the ISCSFileInfo and ISCSConvertedFileInfo objects to pass information into the API to process conversion rules and apply explicit templates.
ICISTransferStream transferStream = fileAPI.getDynamicConversion (m_context, content.getDocumentID ()); // process the stream...
The following sample combines the above features in one method that dynamically converts the alternate rendition of a given content object by using a custom conversion template.
// create the converted file bean and set our properties
ISCSConvertedFileInfo convertedInfo = fileAPI.__createConvertedFileInfo ();
convertedInfo.setConversionLayout ("custom_layout");
convertedInfo.setRendition ("Alternate");
// execute the dynamic conversion
ICISTransferStream transferStream =
fileAPI.getDynamicConversion (m_context, content.getDocumentID (),
convertedInfo);
// do something with the stream...
The SCS Document APIs deal with content in the content server, including the checking in and out of content, content information, and the deletion of content.
This section provides a description of these APIs:
This API deals with the check-in of all content to the content server. For a simple check-in of a file from disk, the following code will work:
// get the checkin api
ISCSDocumentCheckinAPI checkinAPI =
m_cisApplication.getUCPMAPI ().getActiveAPI ().getDocumentCheckinAPI ();
// create an empty content object with the specified content ID
ISCSContent content =
(ISCSContent) m_cisApplication.getUCPMAPI ().createObject(ISCSContent.class);
ISCSContentID contentID =
(ISCSContentID) m_cisApplication.getUCPMAPI ().createObject(ISCSContentID.class);
contentID.setContentID("my_test_file");
content.setContentID(contentID);
content.setAuthor (m_context.getUser ());
content.setTitle ("Custom Title");
content.setSecurityGroup ("Public");
content.setType ("ADACCT");
// get the file stream
File myFile = new File ("c:/test/testcheckin.txt");
ICISTransferStream transferStream =
m_cisApplication.getUCPMAPI ().createTransferStream();
transferStream.setFile(myFile);
// execute the checkin
checkinAPI.checkinFileStream (m_context, content, transferStream);
In many deployments of the content server, there are required extended properties that need to be set for a new piece of content. These properties can be set on the content object via the setProperty() call available to all ICISObject objects. For example, some custom properties can be set as follows:
// set an extended property
content.setProperty ("xCustomProperty", "Custom Value");
You can use the setProperty() method to set all the properties as opposed to calling the setter methods. You can use either the JavaBean name (for example, title) or the native content server property name that the JavaBean property corresponds to (that is, dDocTitle). In the next sample, we will set the title property in three ways, all equivalent:
// set via a standard property setter
content.setTitle ("My Title");
// set a standard property using the JavaBean property name
content.setProperty ("title", "My Title");
// set a property using the native content server property name
content.setProperty ("dDocTitle", "My Title");
This API deals with checking out content from the content server. Content items are identified by their ID.
// get the checkout api ISCSDocumentCheckoutAPI checkoutAPI = m_cisApplication.getUCPMAPI ().getActiveAPI ().getDocumentCheckoutAPI (); // checkout the file checkoutAPI.checkout (m_context, content.getDocumentID ());
The ISCSWorkflowAPI deals with the workflow commands such as approval and rejection, viewing a user's workflow queue, and interacting with the content server workflow engine. The following sample code shows an example of querying the workflow engine for the workflows currently active in the system:
// get the workflow API
ISCSWorkflowAPI workflowAPI =
m_cisApplication.getUCPMAPI ().getActiveAPI().getWorkflowAPI ();
ISCSWorkflowResponse workflowResponse =
workflowAPI.getActiveWorkflows (m_context);
// iterate through the workflows
for (Iterator it = workflowResponse.getActiveWorkflows().iterator();
it.hasNext (); ) {
ISCSWorkflow workflow = (ISCSWorkflow)it.next ();
String name = workflow.getName ();
String status = workflow.getWorkflowStatus ();
System.out.println ("SCS workflow: " + name + "; status = " + status);
}
The most common interaction with workflows is to reject them or approve them and advance them to the next step in the workflow. The following code illustrates how to get a user's personal workflow queue and approve all workflows pending:
// get the workflow API
ISCSWorkflowAPI workflowAPI =
m_cisApplication.getUCPMAPI ().getActiveAPI().getWorkflowAPI ();
// get the workflow queue
ISCSWorkflowQueueResponse queueResponse =
workflowAPI.getWorkflowQueueForUser (m_context);
for (Iterator it = queueResponse.getWorkflowInQueue().iterator(); it.hasNext();) {
ISCSWorkflowQueueItem queueItem =
(ISCSWorkflowQueueItem)it.next();
// approve the workflow
workflowAPI.approveWorkflow(m_context, queueItem.getDocumentID ());
}