Will the repository manager used with MDM be made available to customers?

[Former Member]

Hello KM-TREX Gurus,

The question is whether a single search request can provide the result based on both the structured(data residing in the database) and unstructured data available in an organization?

So far we have come across repository managers for unstructured data residing in different repositories. The contents of these repositories can be Indexed and hence can be searched using a TREX search.

Is there any repository manager available for structured data stored in a database? Or do we have to write it on our own?

We came to know that TREX search can be done in MDM. If so, SAP already has a repository manager available for a database. Will that be made available to the customers in the near future?

Is that repository manager specific to MDM?

If so, do we need to write repository manager for each database?

Please clarify. Any input in this regard will be really helpful and will be greatly rewarded.

Thanks in advance.

Best regds,

Alagammai.

[KarstenH · Accepted solution]

Hi Alagammai,

what we consider a "true" enterprise search solution - an integrated search over business objects (BOs), master data, documents as in KM, and 3rd party indexes - will come step by step.

NetWeaver 2004:

You can integrate various document repositories into KM and thus search over them.

NetWeaver 2004s:

The search engine service (SES) that originates from MDM will deliver as a generic service in the Web AS ABAP. It is able to publish any business object to TREX and then search over it again.

Release after NetWeaver 2004s:

SAP will add the meta search framework that will allow access to both of the above and any other integrated search strategy at the same time, with one search, through one UI.

Will you be at one of the SAP TechEds 2005?

I will speak about that roadmap in Vienna and a colleague will do so in Boston.

Regards,

Karsten

[Former Member · Accepted solution]

hi Karsten,

Thanks a lot for your immediate reply.

From your reply can I come to a conclusion as below:

(1) Single search request through one UI that searches both the unstructured information in the form of files/documents and structured data in any RDBMS like Oracle, SQL Server, etc <b>will be supported after Netweaver 2004s</b>

(2) Or there is <b>no plan at all about enabling TREX to search the structured data</b> stored in any RDBMS like Oracle, SQL Server, etc.

(3) Right now EP6SP12(current release of NW04) supports search only in the unstructured data(documents and files) stored in different repositories.

(4) In future TREX search will be extended to BOs, master data in MDM, 3-party indexes. It will not be made available to structured data stored in any RDBMS like Oracle, SQL server, etc.

We had a business scenario like where we need a single search request to search both in the unstructured information(in the form of documents and files) and structured information stored in the customer's database.

I read through the elearning content published in SDN which is authored by you and one other person and the URL of the same is here as below.

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/documents/a1-8-4/trex - search and classification engine for sap.pdf

In that I came across a statement saying that TREX can be used to search both structured data and unstructured documents in page 29 of that pdf.

(5) What does that statement mean? Does that talks about the future capabilities of TREX? Or the current capabilities of TREX?

(6) In page 10 of the same pdf, I am able to see the search result obtained by searching MDM using TREX. I assumed that it is the search result obtained by searching the MDM database. Am I right?

(7) If it is the search result obtained by searching the MDM database, <b>is there any repository manager being used by TREX to search in MDM</b>?

(8) If so, <b>is that repository manager a generic</b> repository manager that can be used with any RDBMS?

(9) If so, is there any plan of releasing that repository manager to the customer?

(10) If that repository manager is specific to MDM database, <b>can a repository manager be written by the customers to enable TREX to search the structured data</b> stored in any RDBMS?

(11) Does the API provided for developing the repository managers supports this?

Can you please answer all my questions please? I am badly in need of the information from you.

I will not be able to attend any of the SAP TechEds 2005. But my superiors will come there and will meet you. But I am in need of this information now urgently. Can you help me?

Thanks a lot with lots of expectation.

Best regds,

alagammai.

[KarstenH · Accepted solution]

Hi Alagammai,

1-5)

TREX is already being used by various SAP solutions. KM, BI, CRM, SRM, MDM, KW, PLM DMS, and more. Some of these search over documents, some over structured data. All are queried from their specific UIs, though.

=> TREX as the <b>backend engine</b> has long supported both worlds.

What will come <b>after Netweaver 2004s</b> is the framework and UI that queries all these TREX approaches (and optionally other, non-TREX search strategies) at the same time. You can basically consider this to be a meta search framework.

6-11) MDM 3.0 uses TREX to search over the master data in MDM. This has currently no connection to KM, the portal UI goes directly to MDM search, there is no repository manager involved.

TREX (see above) is an engine offering services to many SAP solutions. MDM 3.0 uses them for their purposes, KM for theirs. If you need one UI to query both at the same time <b>with or before Netweaver 2004s</b>, you will either:

- need to write a repository manager for MDM

- write an XML export of master data into a KM repository

- or do it <b>the "cheap" way</b>:

- write a simple search input iView

- put it on a portal page with two iViews that listen for the search event from the input iView

- point one of the listener iViews to search KM and display results, the other to MDM

- this will give you two separate result lists on one page triggered one search

- you can basically do this "cheap" iView event based search of multiple sources for anything searchable that is accessible through the portal - no matter if it's TREX or whatever else performing the actual search.

(but please don't ask me for coding, I only know THAT it is possible)

The concept "TREX is an engine offering services to many SAP solutions." is what I tried to explain with slide 14 of the presentation you linked to below. In the <b>example</b> (and "example" means, you can fill in "MDM" and many other in the place of IC WebClient) given there:

- you query KM from the portal

- KM uses TREX as search service

- any repositories connected into KM are searched that way

- mySAP PLM DMS can be connected to KM by repository manager and be searched as just stated along with other repositories

- mySAP PLM DMS can also use its own TREX connection

- documents in mySAP PLM DMS would then be searched bypassing KM, either in a DMS-specific iView or from SAP GUI.

- IC WebClient (CRM) can have a specific search UI outside the portal

- IC WebClient (CRM) can have a specific search UI in an iView inside the portal

- IC WebClient (CRM) uses its own TREX connection that bypasses KM as there is no repository manager for IC WebClient

- In all of the above you can use one and the same TREX instance or a separate TREX instance for each of the three here used examples

- Using one and the same TREX instance does not produce a common result in the UI, as (in the NW 2004 situation) one application does not know about indexes of the other application

- The common result in one UI will be provided with the meta framework after NW 2004s

- In all of the above each solution (KM, MDM, CRM) may use and display TREX engine services differently. I.e. you may not find the functionality offered on the basis of TREX technology the same in KM as in MDM as in...etc.

It's actually easy:

<b>TREX is a technology provider, not an application.

TREX is used by applications in different ways.</b>

Have a look at that slide 14 while you read this post and I hope it will become clear.

And again:

The future meta framework for ONE access to search over (almost) anything will basically sit between "Apps" and "UI" (referring to slide 14 again).

Wow...can I get this published as a novel maybe?

Usually I do this one only in direct discussion. Because, yes, it does get confusing, I know, although it is actually rather simple...

Regards,

Karsten