ProviderPipeline

---

A search can be carried out via the DataProviders in primedocs and the data is then presented to the user.
This procedure is sufficient for endpoints where all data is already transmitted via a single search query.
In the event that a search query returns essential but not all data, the ProviderPipeline can be used.

The ProviderPipeline makes it possible to store a separate DataProvider for the search. If the user selects the corresponding data record, further details are reloaded via an additional DataProvider.

Searching & Loading

The ProviderPipeline behaves like a normal DataProvider, but is divided into two “phases”:

<ProviderPipeline DisplayName="Zefix">
    <Searching>
        ...
    </Searching>
    <Loading>
        ...
    </Loading>
</ProviderPipeline>

In both phases, DataProviders can be configured — except the ExistingListDataProvider and the ProviderPipeline itself. It is also permitted to use a different DataProvider in the Searching step than in the Loading step.

The two phases differ in the settings they allow:

• Searching: the actual search step. SearchParameters can be defined here; if they are omitted, the search runs automatically over the entire data set without an input mask.
• Loading: here no SearchParameters may be defined. The CodeDataProvider additionally does not take part in the Loading phase, as it has no flat search step that could be re-mapped on load.

The DisplayName is set exclusively on the ProviderPipeline element, not on the providers inside Searching/Loading.

Search parameters & Data loading

SearchParameters can be specified for the search in the Searching step. If they are omitted, the search runs automatically over the entire data set without an input mask.
The search result must be based on the schema of the Object or the ObjectCollection.

The fields of the search result can then be accessed in the Loading step, e.g. to load further details with an ID.
No further SearchParameters may be defined in the Loading step.

Search result in the loading mapping (SearchResultMappingPrefix)

In the Request of the Loading step, the fields of the selected search result are directly available as {Placeholder} (e.g. {uid} in the example below). The Mapping of the Loading step, however, reads only the data of the detail response by default.

If the detail response does not return a required field, the optional SearchResultMappingPrefix attribute on the Loading element also makes the search result available in the mapping:

<Loading SearchResultMappingPrefix="Searching.">
  ...
  <Mapping>
    <!-- from the search result -->
    <Map Source="Searching.uid" Target="uid" />
    <!-- from the detail response -->
    <Map Source="name" Target="name" />
  </Mapping>
  ...
</Loading>

Property	Description
SearchResultMappingPrefix (optional)	Prefix under which the fields of the selected search result become visible in the mapping of the Loading step.

Behaviour:

• The prefix is specified in full, including the separator — Searching. results in Searching.uid. A dot is not added automatically. The prefix is freely selectable in order to avoid name collisions with the fields of the detail response.
• What is addressed are the Target names of the Searching mapping, not the raw fields of the search endpoint.
• The prefix works both in the Source attribute and in the source() function of a SourceExpression or When condition.
• If a Source value starts with the prefix, the lookup happens exclusively in the search result. If the field is missing there, the value stays empty — there is no fallback to the detail response.
• Without the attribute, the loading mapping only sees the detail response.

Example

In the example, company data is queried via the Zefix service.

The name and identification number are provided as search results. If the user selects the search results, the address data is automatically loaded.

<ProviderPipeline DisplayName="Zefix">
  <Searching>
    <HttpDataProvider>
      <SearchParameters>
        <Text Id="Query" Label="Query" />
      </SearchParameters>
      <Configuration>
        <Step>
          <Request Method="Post">
            <Url>https://www.zefix.admin.ch/ZefixPublicREST/api/v1/company/search</Url>
            <Header Name="Authorization" Value="Basic [ZEFIX-AUTH-KEY]" />
            <Header Name="Content-Type" Value="application/json" />
            <Header Name="accept" Value="application/json" />
            <Body>{
  "name": "{Query}",
  "activeOnly": true
}</Body>
          </Request>
          <Response>
            <Data JsonPath="$.[*]">
              <Mapping>
                <Map Source="uid" Target="uid" />
                <Map Source="name" Target="name" />
              </Mapping>
            </Data>
          </Response>
        </Step>
      </Configuration>
    </HttpDataProvider>
  </Searching>
  <Loading>
    <HttpDataProvider>
      <Configuration>
        <Step>
          <Request Method="Get">
            <Url>https://www.zefix.admin.ch/ZefixPublicREST/api/v1/company/uid/{uid}</Url>
            <Header Name="Authorization" Value="Basic [ZEFIX-AUTH-KEY]" />
            <Header Name="Content-Type" Value="application/json" />
            <Header Name="accept" Value="application/json" />
          </Request>
          <Response>
            <Data JsonPath="$.[*]">
              <Mapping>
                <Map Source="uid" Target="uid" />
                <Map Source="name" Target="name" />
                <Map Source="address.street" Target="street" />
                <Map Source="address.houseNumber" Target="houseNumber" />
                <Map Source="address.city" Target="city" />
                <Map Source="address.swissZipCode" Target="swissZipCode" />
              </Mapping>
            </Data>
          </Response>
        </Step>
      </Configuration>
    </HttpDataProvider>
  </Loading>
</ProviderPipeline>