Function1

Last week we mentioned the difference between the Knowledge Directory and the Document Repository, and mentioned that the Knowledge Directory contains cards, which basically contain metadata (properties) and a Document Open URL. The neat thing about this is that cards don’t necessarily have to represent documents, and the doc open URL doesn’t even have to open a document.

For example, BID’s portal has a crawler that indexes Service Requests from Siebel. This allows anyone in the company to search for error messages or existing trouble ticket numbers, and get an easy view of Service Requests to utilize that institutional knowledge.

Imagine another hypothetical application where you’d like to track customer information. Instead of simply gatewaying access to your CRM system, you could create custom properties and a custom crawler to bring all of that information into the Knowledge Directory as cards. These cards could have properties with different permissions set, so users would see different information based on their role. The Document Open URL would then point to your custom code that displays information about the customers:

Notice your custom code doesn’t need to be restricted by the portal’s property page; you can do anything you want with that Document Open URL, such as taking a stock ticker and getting a real-time quote, or displaying the obligatory Google Map based on address.

Why would you want to implement an application like this? A couple of reasons come to mind:

1. You can use custom properties to capture any information you want, and have the portal’s rich ACL (Access Control List) infrastructure to custom-tailor who sees what properties.
2. These properties can be searchable in the portal, so when users search for content about the customer or a product, this rich information page could be displayed.
3. Other functionality in the portal that is typically thought of in the context of documents is now available to your application, since these cards are just objects in the Knowledge Directory. For example, you could create a snapshot portlet to display customers that have been updated recently, or customers that have had service requests open for more than 10 days, or customers in a particular region, etc.

Use your imagination, and by leveraging the rich functionality of the Knowledge Directory and associated subsystems, you can develop incredibly secure, rich applications with little effort!