Difference between revisions of "Opentaps Search Feature"
(→Architecture) |
|||
| Line 1: | Line 1: | ||
| − | + | This is a conceptual document and the features described here are being implemented | |
__TOC__ | __TOC__ | ||
| Line 7: | Line 7: | ||
The basic idea is to use [https://www.hibernate.org/410.html Hibernate Search] to index data in the opentaps database, and then have a search tool which allows you to find results based on keywords rather than explicit parameters like on a find form. This is however different than [http://www.google.com/enterprise/gsa/ Google Enterprise Search] which is designed to index documents rather than database table values. However, the overall architecture should support integration to external search interfaces such as [http://www.google.com/enterprise/gsa/ Google Enterprise Search] fairly easily. | The basic idea is to use [https://www.hibernate.org/410.html Hibernate Search] to index data in the opentaps database, and then have a search tool which allows you to find results based on keywords rather than explicit parameters like on a find form. This is however different than [http://www.google.com/enterprise/gsa/ Google Enterprise Search] which is designed to index documents rather than database table values. However, the overall architecture should support integration to external search interfaces such as [http://www.google.com/enterprise/gsa/ Google Enterprise Search] fairly easily. | ||
| − | + | Now these are just my notes. | |
| − | < | + | Each search service implements a ''SearchServiceInterface'' : |
| + | - setKeywords(String) -> what to search | ||
| + | - setPageSize(int) -> for paginating the results | ||
| + | - setPageStart(int) -> for paginating the results | ||
| + | - search() -> does the search | ||
| + | - getResults() -> returns the List<Entity> found | ||
| − | Each domain has a search capability | + | Each domain has a search capability, ''AccountsSearch'' -> List<Account>, ''SalesOpportunitySearch'' -> List<SalesOpportunity> ... which can have domain specific search options. |
| − | |||
| − | + | And each application (CRM, purchasing, etc.) can have a Search Service which give an application specific interface to search any of the application related domains. | |
| − | which | ||
| − | |||
| − | + | For example ''CrmSearchService'' provides getAccounts() getContacts() getSalesOpportunities() and could provide getParties() which would return any CRM related parties (Accounts + Contacts ...), and purchasing just has a search which allows you to getSuppliers() for now. | |
| − | + | The results of the search should be passed to our GWT EntityListViews so that the webapps could display them. | |
| − | + | Hibernate search should be set to configure entities and fields and their weights | |
so for example, if I want SalesOpportunity.opportunityName to weigh 10x as much as SalesOpportunity.description | so for example, if I want SalesOpportunity.opportunityName to weigh 10x as much as SalesOpportunity.description | ||
similar to applications/product/config/prodsearch.properties | similar to applications/product/config/prodsearch.properties | ||
| − | + | The other thing we need is AOP on the delegator to index the entities as they are stored by delegator and do it in 1 transaction prior to ofbiz committing so we don't open up more transactions | |
| − | + | Here's a good thought experiment: | |
what if we integrate in Google Search Appliance which indexes your documents | what if we integrate in Google Search Appliance which indexes your documents | ||
so...let's say it's part of CRM and we want to link to documents | so...let's say it's part of CRM and we want to link to documents | ||
| Line 34: | Line 36: | ||
I guess what we need is a method in CRMSearchInterface/Impl which returns a link and a description for each result in the List<Document> | I guess what we need is a method in CRMSearchInterface/Impl which returns a link and a description for each result in the List<Document> | ||
and then implement Google Search Appliance as one kind of DocumentDomainSearchInterface | and then implement Google Search Appliance as one kind of DocumentDomainSearchInterface | ||
| − | |||
Revision as of 20:19, 8 July 2009
This is a conceptual document and the features described here are being implemented
Contents
Architecture
The basic idea is to use Hibernate Search to index data in the opentaps database, and then have a search tool which allows you to find results based on keywords rather than explicit parameters like on a find form. This is however different than Google Enterprise Search which is designed to index documents rather than database table values. However, the overall architecture should support integration to external search interfaces such as Google Enterprise Search fairly easily.
Now these are just my notes.
Each search service implements a SearchServiceInterface :
- setKeywords(String) -> what to search - setPageSize(int) -> for paginating the results - setPageStart(int) -> for paginating the results - search() -> does the search - getResults() -> returns the List<Entity> found
Each domain has a search capability, AccountsSearch -> List<Account>, SalesOpportunitySearch -> List<SalesOpportunity> ... which can have domain specific search options.
And each application (CRM, purchasing, etc.) can have a Search Service which give an application specific interface to search any of the application related domains.
For example CrmSearchService provides getAccounts() getContacts() getSalesOpportunities() and could provide getParties() which would return any CRM related parties (Accounts + Contacts ...), and purchasing just has a search which allows you to getSuppliers() for now.
The results of the search should be passed to our GWT EntityListViews so that the webapps could display them.
Hibernate search should be set to configure entities and fields and their weights so for example, if I want SalesOpportunity.opportunityName to weigh 10x as much as SalesOpportunity.description similar to applications/product/config/prodsearch.properties
The other thing we need is AOP on the delegator to index the entities as they are stored by delegator and do it in 1 transaction prior to ofbiz committing so we don't open up more transactions
Here's a good thought experiment: what if we integrate in Google Search Appliance which indexes your documents so...let's say it's part of CRM and we want to link to documents so we drop a new DocumentDomainSearchInterface/Impl into opentaps CRM I guess what we need is a method in CRMSearchInterface/Impl which returns a link and a description for each result in the List<Document> and then implement Google Search Appliance as one kind of DocumentDomainSearchInterface
