• State Verified Answer
  • Replies 5 replies
  • Subscribers 94 subscribers
  • Views 1056 views
  • Users 0 members are here
Options
Related

Use a different culture for Composition API search

daniel.storck
over 1 year ago

Hello,

in our company we use Person.UID_DialogCulture as the primary display language in both our Angular web application and the old Webportal (since the Webportal overwrites the browser culture if person culture is set).

We have many API endpoints in the Composition API created with the `FromTable()` method especially in order to enable the lucene index search on translated columns. Unfortunately, the search that is invoked by the Composition API automatically uses the Browser Culture for the lucene search query. Hence a Person which for example has EN as his primary browser culture but Person.UID_DialogCulture = QBM-CULT-de-DE is not able to get a proper result as the user expects to search for a german term but the lucene search query searches in the english dictionary behind the scenes.

Is there any way to work around this behavior?

  • 0 over 1 year ago

    Hello Daniel,

    How are you calling the search? Is that the search executed by the "search" URL parameter?

    if you are calling the API from within a session associated with a user, the Person.UID_DialogCulture should take precedence. (I think the search log contains the culture it is using.) The behavior you are describing sounds like a bug.

  • 0 over 1 year ago in reply to Hanno Bunjes

    Hello Hanno,

    yes we are utilizing the search by the auto generated "search" url parameter. In the AppServer.log you can clearly see that Person.UID_DialogCulture is ignored and the accept-language culture is being used by lucene search query. Since this seems not to be intended i will create a SR for that.

  • 0 over 1 year ago in reply to daniel.storck

    Could you please just confirm that the session uses the expected culture?

    The client makes API request to imx/sessions/portal: I am assuming you are using the "portal" API project.

    The response includes the session's culture:

  • 0 over 1 year ago in reply to Hanno Bunjes

    thank you for the hint, its going into the right direction. We are using a custom API project. This custom project seems not to return a Culture property. When performing a login against the "portal" API project, the culture is returned.

    Custom API project login response:

    {
        "Status": {
            "PrimaryAuth": {
                "Display": "DGZ012",
                "Uid": "33b79ac2-71d5-4353-87cc-76d36d55d4ae",
                "IsAuthenticated": true,
                "AuthTime": "2022-08-17T05:42:32.4226469Z"
            },
            "SecondaryAuth": {
                "IsAuthenticated": false,
                "IsEnabled": false,
                "Name": "NotRequired"
            }
        },
        "Config": [

    "portal" login response:

    {
        "Status": {
            "PrimaryAuth": {
                "Display": "DGZ012",
                "Uid": "33b79ac2-71d5-4353-87cc-76d36d55d4ae",
                "IsAuthenticated": true,
                "AuthTime": "2022-08-17T05:42:57.6115941Z"
            },
            "SecondaryAuth": {
                "IsAuthenticated": false,
                "IsEnabled": false,
                "Name": "NotRequired"
            },
            "Culture": "de-DE"
        },
        "Config": [

  • +1 over 1 year ago in reply to daniel.storck

    Hi Daniel,

    This explains the behavior.

    To use the person's culture for the session, add the SetSessionCulture plugin when building the API. Just add this code to your API initialization:

            public void Build(IApiBuilder builder)
        {
            builder.AddPlugin(new QER.CompositionApi.Person.SetSessionCulture());
        }