How-To: Making Application Content Accessible to Site-Wide Search

I. Introduction

There are essentially two different scenarios in which developers will want to include application content within the scope of the SWS package:

1. When developing applications which recycle an object type first introduced elsewhere in the system.
2. When developing applications which define their own object types.

II. Scenarios

1. Verify that those application object types within your application which you'd like to make searchable meet the SWS requirements listed below.
2. For each such searchable object type, provide a display page for that type; see below for details on this..
3. For each such object type, register this object type and the associated display pages using the pot_service PL/SQL package; see below for details on this.

1. Object types must implement the sws_display interface.
2. Object types must implement the sws_indexing interface and/or store the data in acs_contents.

• object_id_implement_p, which checks whether the object type of an object implements an interface when given an object id, and
• object_type_implement_p, which checks whether the object type implements an interface when given that object type itself.

declare
    v_implement_p     char(1);
begin
    -- 't' or 'f'
    v_implement_p := object_type_implement_p ('sws_display', 'pl/sql', content_revision);
end;

On display page attributes:

After the SWS requirements have been verified for the searchable object types, applications will need to register the object types used and, for each object type, specify the display page attribute. So for each searchable object type there should be a page to handle the display for the object type or an appropriate redirect page. Consider, for example, a file-storage application built on top of the ACS Content Repository. In that case the file-storage application would use the content_revision object type.

begin
    pot_service.register_object_type (
	package_key		=> 'file-storage',
	object_type		=> 'content_revision'
    );

    pot_service.set_obj_type_attr_value (
	package_key		=> 'file-storage',
	object_type		=> 'content_revision',
	attribute		=> 'display_page',
	attribute_value		=> 'file?file_id='
    );    
end;

Procedure:

1. Implement the sws_display interface methods.
2. Implement the sws_indexing interface if the data is not stored in acs_contents or if a preferred searchable representation of the data is stored elsewhere.
3. Register the object type with the pot_service

In the PL/SQL environment, object types are assumed to have names prefixed by the package. Thus when an object type implements an interface, the methods specified for the interface are declared and defined within the object type package itself. Another option ,which avoids modification to the object type package, is have a separate package provide the methods. In the call to register the object type, an optional parameter may be provide to specify the package that has the interface methods. SWS requires object types to implement the 'sws_display' interface. The sws_display interface consists of six methods:

    function sws_title (
	object_id		in acs_objects.object_id%type
    ) return varchar2;

    function sws_url (
	object_id           in acs_objects.object_id%type
    ) return varchar2;

    function sws_summary (
	object_id		in acs_objects.object_id%type
    ) return varchar2;

    function sws_req_permission (
	object_id		in acs_objects.object_id%type
    ) return varchar2;

    function sws_site_node_id (
	object_id           in acs_objects.object_id%type
    ) return site_nodes.node_id%TYPE;
 
    function sws_application_id (
	object_id	    in acs_objects.object_id%type
    ) return apm_packages.package_id%TYPE;

    function sws_url (
	object_id           in acs_objects.object_id%type
    ) return varchar2
    is        
	url			varchar2(3000);	    
    begin 
	url := sws_service_interface.sws_url (
	       object_id	    => object_id 
	);
	return url||to_char(object_id);
    end;

    function sws_site_node_id (
	object_id           in acs_objects.object_id%type
    ) return site_nodes.node_id%TYPE
    is
	node_id		    site_nodes.node_id%type;
    begin
	node_id := sws_service_interface.sws_site_node_id (
			object_id	    => object_id
		   );
	return node_id;         
    end;

    function sws_application_id (
	object_id	    in acs_objects.object_id%type
    ) return apm_packages.package_id%TYPE
    is
	v_application_id	apm_packages.package_id%type;
    begin
	v_application_id := sws_service_interface.sws_application_id (
				object_id	=> object_id
			    );
	return v_application_id;
    end;

The last necessary step is to register the object as implementing the sws_display interface.

    begin
       acs_interface.assoc_obj_type_with_interface (
           interface_name           => 'sws_display' ,
	   programming_language     => 'pl/sql'      ,
           object_type              => '',
	   object_type_imp          => '' -- this optional parameter 
	                                                   specifies another package 
							   that provides the 
							   implementation.
       );
    end;

2. Implement the sws_indexing interface

This interface consists of one method, sws_index_proc (rid, blob). SWS uses the sws_indexing interface to provide search functionality to allow object types to specify a different content to be indexed instead of the one stored in acs_contents table. If the object type does not implement this interface, then the content stored in acs_contents is used. This option can prove useful in scenarios in which the textual description of the object is stored in another location and the graphic representation is stored in acs_contents or when data is stored in a different table then acs_contents. A good working example of this is the current ACS Content Repository, wherein content is stored in cr_revisions. Copying the content from cr_revisions to acs_contents would be a waste of space. Instead of copying the data over, for every entry of cr_revisions there is an entry in acs_contents with an empty blob. The code below is added to the content_revision package:

create or replace package body content_revision
as
    ....
    procedure sws_index_proc (
	object_id	    in acs_objects.object_id%TYPE,
	bdata		    in out nocopy blob
    ) 
    is
	v_bdata		    blob; 
	v_size		    integer;
    begin
	select content into v_bdata 
	from cr_revisions 
	where revision_id = object_id;
	
	v_size := dbms_lob.getlength(v_bdata);

	if v_size > 0 then 
	    dbms_lob.copy (
		dest_lob    => bdata,
		src_lob	    => v_bdata,
		amount	    => v_size
	    );
	end if;
    end sws_index_proc;
end content_revision;

create or replace trigger content_revision_itrg
after insert on cr_revisions
for each row
declare
    v_bdata	blob;
    v_size	integer;
begin
   
    insert into acs_contents (
	content_id,
	searchable_p)
     values ( 
	:new.revision_id,
	't'
    );
end;
/

create or replace trigger content_revision_utrg
after update on cr_revisions
for each row
declare
    v_bdata	blob;
    v_size	integer;
begin
    update acs_contents 
    set nls_language    = :new.nls_language,
	mime_type	= :new.mime_type
    where content_id	= :new.revision_id;
end;
/

create trigger content_revision_dtrg
after delete on cr_revisions
for each row
declare
begin
    delete from acs_contents
    where content_id = :old.revision_id;
end;
/

    begin
       acs_interface.assoc_obj_type_with_interface (
           interface_name           => 'sws_indexing' ,
	   programming_language     => 'pl/sql'      ,
           object_type              => ''
	   object_type_imp          => '' -- (optional) provides the implementation in this package
	                                                   instead of object type package
	                                                   
       );
    end;

This process is the same for scenario 1 above. The application registers the object type and the display page for that instance of the object type.

III. Notes

IV. Revision History