თუ თქვენ ხელით კოდირება ADF ფაილი და აკეთებს უამრავ კოდი / იმპორტი / ტესტი ციკლის, use the version number to make your life easier.

მე სიძულვილის ვაღიაროთ ეს, მაგრამ სანამ ამ კვირაში, I was always deleting the ADF and re-importing it. This would break my business data columns and make me re-wire them. All unnecessary.

File this under "it’s obvious once you see it".

მაგალითი:

<LobSystem
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://schemas.microsoft.com/office/2006/03/BusinessDataCatalog BDCMetadata.xsd"
  გაცნობის="WebService"
  მობილური="1.2.0.0" სახელი="xyzzyDocumentReview"
  xmlns="http://schemas.microsoft.com/office/2006/03/BusinessDataCatalog">

Change that version and re-import and the existing business data column uses the updated version automatically with no additional configuration required.

</ბოლო>

გამოწერა ჩემი დღიური.

In my on-going attempts at providing a more useful lookup column using BDC, I hit a wall with the BDC picker. If you haven’t see it, the BDC picker is similar to a people picker except that it works with columns of type "business data".

You access the picker by clicking on the open book icon of a business data column as shown:

The above image shows a business data column called "Master Document Id". That column is connected, via BDC, to a web service. The web service returns two columns of information: Document ID and Title. The business purpose here is to provide a "this document is based on" ფუნქცია. Users select a "master" document and when they save, an event receiver copies meta data fields from the referenced master.

სტანდარტულად, the BDC picker looks like this when I search for a document whose ID = "38":

That’s helpful, but not good enough. People don’t think in terms of IDs, they think in terms of titles and/or other meta data. The picker allows you to search on other columns (e.g. სათაური) but won’t show the actual list of titles it found, just their DocId’s as shown here:

(The screen shot isn’t so great because I didn’t pick a search that returns any valid results, but you can see that if it had found some results, it would only have shown DocId’s, not titles).

I searched high and low for the answer to this and failed. ჩემმა კოლეგამ, the venerable Jonathan Bradshaw, had faced and solved this issue. When I reached out to him for help, he pointed me in the right direction.

Configure the picker to show multiple columns via the "ShowInPicker" property in the ADF:

<ქონების სახელი="ShowInPicker" გაცნობის="System.Boolean">ნამდვილი</ქონების>

In more detail:

  <!-- სათაური -->
  <TypeDescriptor TypeName="System.String" სახელი="სათაური" >
    <LocalizedDisplayNames>
      <LocalizedDisplayName LCID="1033">სათაური</LocalizedDisplayName>
    </LocalizedDisplayNames>
    <უძრავი ქონება>
      <ქონების სახელი="DisplayByDefault" გაცნობის="System.Boolean">ნამდვილი</ქონების>
      <ქონების სახელი="ShowInPicker" გაცნობის="System.Boolean">ნამდვილი</ქონების>
    </უძრავი ქონება>
  </TypeDescriptor>

Setting this property does introduce a minor problem. As soon as you set it once, you need to set it for every column you want to show. ჩემს შემთხვევაში, BDC picker showed DocId by default. თუმცა, once I added "ShowInPicker" to Title, DocId no longer displayed. I solved that by explicitly setting the ShowInPicker property for Doc ID.

Here is the result:

(I’ll explain the odd-looking "168 – CamlSchema.xsd" construction in a future blog post. In short, it’s a concatenated string that allows for a slightly better user experience).

რა თქმა უნდა, having written this blog entry, I just did a search for "ShowInPicker" and found numerous hits, including this one: http://msdn2.microsoft.com/en-us/library/ms583986.aspx. It explains the meaning of that property along with some other good BDC stuff.

</ბოლო>

გამოწერა ჩემი დღიური!

მე კიდევ ერთხელ შეიმუშაოს BDC ADF ფაილი ხელით (so that I can build up my "get off my lawn!" cred) და მოხვდა ამ ლამაზი შეცდომა:

"Application definition import failed. შეცდომა:"

როგორც ხედავთ, აქ არის შეცდომა, მაგრამ … ეს არ მეუბნებოდა, რა არის.

ჩემს შემთხვევაში, the issue turned out that I had started off with a functional ADF for a different project that connected to a database and executed a SQL query against a view. In this new project, I am calling a method on a web service. I had stripped out the DB specific stuff and added my web service stuff, but failed to update the <LobSystem>’s Type attribute. I switched it to "WebService" and I happily moved on to newer and more exciting import errors, which were handled in due course.

Here is the wrong LobSystem:

<LobSystem
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=http://schemas.microsoft.com/office/2006/03/BusinessDataCatalogBDCMetadata.xsd
Type="Database"
Version="1.0.0.0" Name="xyzzy"
xmlns="http://schemas.microsoft.com/office/2006/03/BusinessDataCatalog">

This is correct:

<LobSystem
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=http://schemas.microsoft.com/office/2006/03/BusinessDataCatalogBDCMetadata.xsd
Type="WebService"
Version="1.0.0.0" Name="xyzzy"
xmlns="http://schemas.microsoft.com/office/2006/03/BusinessDataCatalog">

</ბოლო>

განახლების: ეს MSDN განთავსებას აქვს რამდენიმე საინტერესო დაკვირვებების ეხლა JXJ საფუძველზე, ძირითადად უარყოფითი, გამოცდილების მიდის ქვემოთ ეს გზა: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2623565&SiteID=1

We have a business scenario where we need to link two documents libraries via a common "document ID" სფეროში.

We often use a lookup column to implements links like this. There are several drawbacks to lookup columns, სამი რომელთაგან:

1. Only one column from the lookup lookup library can be linked.
2. შესრულებით: The source library could contain hundreds of entries. That’s too many entries in the lookup.
3. ძიება: There is no integrated search. I don’t mean in the MOSS sense of search, მაგრამ არ არსებობს გზა მოძებნონ / გავფილტროთ on მრავალი სვეტის წყაროდან დოკუმენტის ბიბლიოთეკა და იქნებიან რგოლი გსურთ.

გასაცემი BDC, we can use a "business data" column type and it provides a superior search and even allows multiple columns of data to appear in list views.

I’ve had some preliminary success with this approach and plan to write more about it.

If you’ve worked this angle before and have any comments, please share!

</ბოლო>

მე მუშაობის BDC დღეს, coding ADF files by hand and generating myself some errors. One such error:

განაცხადის განმარტება იმპორტი ვერ განხორციელდა. შეცდომა: შეუძლებელია გაცნობის აღწერილი TypeDescriptor ნახვა TypeName. პარამეტრის სახელი: typeName შეცდომა იყო შეექმნა ან ადრე ხაზი: '35’ და თანამდებობა: ’20’.

MOSS ნაჩვენები ეს შეცდომა, როდესაც მე შევეცადე იმპორტი ADF XML ფაილი.

მე გამოკვლეული Internets და აღმოჩნდა, რომ მე მითითება დისტანციიდან ინსტანციის სახელი (საწყისი <LobSystemInstance>) ჩემს <TypeDescriptor> კვანძის, როდესაც მე უნდა მითითებული დისტანციიდან სახელი თავად (საწყისი <LobSystem>).

არასწორი:

<TypeDescriptor TypeName="Conchango.KeyValue, Lob ინსტანციის სახელი" Name="KeyValue">

შეასწორეთ:

<TypeDescriptor TypeName="Conchango.KeyValue, Lob სახელი" Name="KeyValue">

იმედი მაქვს, ეს ერთი ნახტომი ვინმე საათში ან ორი დრო.

</ბოლო>

გამოწერა ჩემი დღიური!

მე გამოწვეული BDC შეცდომა ამ კვირაში, რომ გამოიხატება თავად ინტერფეისი და 12 hive ჟურნალი at runtime.

პირველი, ამ გამოჩნდა ინტერფეისი:

ვერ იპოვა სფეროებში ჩასასმელი ყველა იდენტიფიკატორი ღირებულებები სწორად შესრულდეს SpecificFinder MethodInstance ერთად სახელი … დარწმუნდით შეტანის პარამეტრები აქვს TypeDescriptors ასოცირდება ყოველ იდენტიფიკატორი განისაზღვრება ამ პირის.

აქ ეკრანზე დარტყმას:

მე შეიძლება გამოიწვიოს ამ გზავნილის გამოჩნდება 12 hive ჟურნალი სურვილისამებრ (using my patented high-tech-don’t-try-this-at-home "საიდუმლო შეცდომები" მეთოდი):

11/14/2007 09:24:41.27 w3wp.exe (0x080C) 0x0B8C SharePoint Portal Server Business Data 6q4x High Exception in BusinessDataWebPart.OnPreRender: System.InvalidOperationException: იდენტიფიკატორი ღირებულება ”, ტიპის ”, არასწორია. Expected Identifier value of Type ‘System.String’. ზე Microsoft.Office.Server.ApplicationRegistry.MetadataModel.Entity.FindSpecific(ობიექტის[] subIdentifierValues, LobSystemInstance lobSystemInstance) ზე Microsoft.SharePoint.Portal.WebControls.BdcClientUtil.FindEntity(პირი პირი, ობიექტის[] userValues, LobSystemInstance lobSystemInstance) ზე Microsoft.SharePoint.Portal.WebControls.BusinessDataItemBuilder.GetEntityInstance(წევრის desiredView) ზე Microsoft.SharePoint.Portal.WebControls.BusinessDataDetailsWebPart.GetEntityInstance() ზე Microsoft.SharePoint.Portal.WebControls.BusinessDataDetailsWebPart.SetDataSourceProperties()

მე ჩხრეკა გარშემო და აღმოაჩინა ლიდერობს MSDN ფორუმზე, but they weren’t enough for me to understand what I was doing wrong. I watched a webcast by ტედ Pattison რომ ჩემი კომპანია აქვს squirreled მოშორებით სერვერზე და მოვიდა ესმოდეს ჩემი პრობლემა.

ჩემი ADF, მე დამაკავშირებელი SQL მონაცემთა ბაზაში, როგორც ნაჩვენებია:

            <ქონების სახელი="RdbCommandText" გაცნობის="System.String">
              <![CDATA[
                SELECT
                      , CARRIER_ID, EFFDT, DESCR, EFF_STATUS, TAXPAYER_ID, NETWORK_ID, FRT_FORWARD_FLG, ALT_NAME1, ALT_NAME2, LANGUAGE_CD,
                      ქვეყანა, ADDRESS1, ADDRESS2, ADDRESS3, ADDRESS4, ქალაქი, NUM1, NUM2, HOUSE_TYPE, ADDR_FIELD1, ADDR_FIELD2, ADDR_FIELD3,
                      COUNTY, სახელმწიფო, საფოსტო, GEO_CODE, IN_CITY_LIMIT, COUNTRY_CODE, ტელეფონი, EXTENSION, ფაქსი, LAST_EXP_CHK_DTTM, FREIGHT_VENDOR,
                      INTERLINK_DLL, TMS_EXCLUDE_FLG
                 (nolock)
                WHERE
                  (Leas <> წილი ') და
                  (დაწევა(CARRIER_ID) >= ქვედა(@ MinID)) და
                  (დაწევა(CARRIER_ID) <= ქვედა(@ MaxId)) და
                  (დაწევა(DESCR) LIKE ქვედა(@ InputDescr))
                ]]>
            </ქონების>

მე იმ პირობით, რომ SQL ეხლა DBA პირი და მე მოცემული უნდა გვესმოდეს, რომ ეს სპეციალური view they created just for me. The unique key there is CARRIER_ID.

აქ არის bug გავაცანი:

      <იდენტიფიკატორების>
        <განსაზღვრა სახელი="CARRIER_ID" TypeName="System.String" />
        <განსაზღვრა სახელი="DESCR" TypeName="System.String" /> 
      </იდენტიფიკატორების>

სადღაც ხაზის გასწვრივ, მე მოახერხა აღრეული თავს მეტი მნიშვნელობა <იდენტიფიკატორების> and added DESCR even though it’s not actually an identifier. I took DESCR out of the identifiers set and presto! ეს ყველაფერი მუშაობდა.

I hope this saves someone some grief 🙂

მე შენიშნა რაღაც უხერხულ და არასაჭირო ხელით კოდირებით გამოჩნდება RdbCommandText ზოგიერთ მაგალითები (მათ შორის MSDN დოკუმენტაცია).

I wanted to point out to newcomers to BDC that commands can be wrapped inside a CDATA tag in their "natural" form. ასე რომ,, ამ უხერხულ მშენებლობა:

<ქონების სახელი="RdbCommandText" გაცნობის="System.String">
  SELECT dbo.MCRS_SETTLEMENT.id, dbo.MCRS_SETTLEMENT.settlement from dbo.MCRS_SETTLEMENT 
    WHERE (id &gt;= @MinId) და (id &ლ;= @ MaxId)
</ქონების>

can be better represented this way:

<ქონების სახელი="RdbCommandText" გაცნობის="System.String">
<![CDATA[
SELECT dbo.MCRS_SETTLEMENT.id, dbo.MCRS_SETTLEMENT.settlement from dbo.MCRS_SETTLEMENT
WHERE (id >= @MinId) და (id <= @MaxId)
]]>
</ქონების>

</ბოლო>

BDC Primer

Intro to BDC

I needed to wire up MOSS to a SQL database via BDC. For testing/POC purposes, I wanted to embed the SQL account user id and password in the ADF. Starting with ეს თარგი (http://msdn2.microsoft.com/en-us/library/ms564221.aspx), მე შეიქმნა ADF რომ აკავშირებს კონკრეტულ SQL სერვერზე მაგალითად და ჟურნალები in with კონკრეტული მომხმარებლის ID და პაროლი და უჩვენა ამ snippet:

  <LobSystemInstances>
    <LobSystemInstance სახელი="ClaimsInstance">
      <უძრავი ქონება>
        <ქონების სახელი="AuthenticationMode" გაცნობის="System.String">ი</ქონების>
        <ქონების სახელი="DatabaseAccessProvider" გაცნობის="System.String">SqlServer</ქონების>
        <ქონების სახელი="RdbConnection მონაცემთა წყარო" გაცნობის="System.String">ფაქტობრივი სერვერზე  ფაქტობრივი მაგალითად</ქონების>
        <ქონების სახელი="RdbConnection პირველადი კატალოგი" გაცნობის="System.String">ფაქტობრივი საწყის კატალოგი</ქონების>
        <ქონების სახელი="RdbConnection ინტეგრირებული უსაფრთხოების" გაცნობის="System.String">SSPI</ქონების>
        <ქონების სახელი="RdbConnection გაზიარება" გაცნობის="System.String">ყალბი</ქონების>

        <!-- ეს არის ძირითად ღირებულებებზე: -->
        <ქონების სახელი="RdbConnection მომხმარებლის ID" გაცნობის="System.String">actual მომხმარებლის ID</ქონების>
        <ქონების სახელი="RdbConnection პაროლი" გაცნობის="System.String">ფაქტობრივი პაროლი</ქონების>
        <ქონების სახელი="RdbConnection Trusted_Connection" გაცნობის="System.String">ყალბი</ქონების>

      </უძრავი ქონება>
    </LobSystemInstance>
  </LobSystemInstances>

ეს არ არის საუკეთესო პრაქტიკა, but it’s useful for a quick and simple configuration for testing. This was surprisingly difficult to figure out. I never found a functional example with search keywords:

• adf ჩაშენებულ userid და პაროლი
• იგივე მომხმარებლის ID და პაროლი adf
• იგივე მომხმარებლის ID და პაროლი adf BDC
• SharePoint BDC პრემიერის
• SharePoint embed მომხმარებლის ID და პაროლი adf

</ბოლო>

გამოწერა ჩემი დღიური.