Hello Jimmy,

Yes, we've reviewed this case with our architect team. We have verified that this scenario is one of the advanced relationship scenarios that we will support in the next release. It's unlikely to have workaround for this case, because the support for these scenarios need to be implemented in an end-to-end fashion. The entire range of the toolset, from the repositories, frameworks to the designer tools need to be enhanced altogether, while at the same time re-running all unit tests the existing simpler cases to ensure no regressions.

The good news is that we've raised this feature to a higher priority in our roadmap. We're expecting a feature-complete beta build to be available in early March. We'll keep you posted on this update.

Thanks!

Glad to hear everything works out great for you!

If you've submitted any Crosslight apps to Store, please let us know and we'd love to see it in action. :)

On top of Yudi's response, of course, you'll also need to create a custom class that derives from WebApiAccountService where you need to override the RegisterDefaultAuthenticator and GetDefaultAuthenticator methods, to link the default authenticator to the one you created in the step above. See the following example.

public class MyWebApiAccountService : WebApiAccountService
{

    protected override void RegisterDefaultAuthenticator()    {
        this.AuthenticationService.Register<CustomWebApiAuthenticator>(this.AccountServiceId);
    }
     
    protected override WebApiAuthenticator GetDefaultAuthenticator()
    {
        return this.AuthenticationService.GetAuthenticator<CustomWebApiAuthenticator>();
    }


}

Finally, remember to replace the new authenticator in the AppService.

           
ServiceProvider.AddService<IAccountService, MyWebApiAccountService>();

And that's the beauty of IoC design pattern which is heavily used in Crosslight. It allows you to extend or replace most functionalities in Crosslight, just like that.

Hope this helps.

Hello Jimmy,

I was previously assuming that you already have a custom way to call the SP. Our best practice is usually generating the functions automatically from the EDMX to avoid mistakes in parameters definition, which is also goodfor maintenance. When the specific SP is added to the EDMX, Intersoft Entity Designer will automatically generate the code in both EntityContext and in the Controller. Technically, the underlying code in the EntityContext actually use "Context" to perform the SP call which is completely fine since it routes the call to SP directly without requiring LINQ.

You can then simply call the SP in your query method such as shown in the simple code snippet below:

[HttpGet]public QueryResult ItemsByName(string name, ODataQueryOptions<Item> options)
{
    return new QueryResult()
    {
        Results = this.GetItemsByName(name), 
        InlineCount = this.Request.GetInlineCount() 
    };
}

In the above example, the query calls the GetItemsByName method which was an auto-generated method fromthe Intersoft Entity Designer.

However, please note that the InlineCount might not work using the built-in Request.GetInlineCount method since the actual query is performed with a custom SP. In that case, you'll need to come up with another SP that returns the total number of rows of the query. But, if the app doesn't require paging, then InlineCount is not required.

Hope this helps!

Hello Jimmy,

The incremental loading, filtering and paging are actually features that were built into the EntityController. Behind the scene, the options passed from the client is transformed into LINQ expression which is then sent to theserver for execution.

Per our experience, it will be quite tedious to achieve these functions at SP level, since you need to parse each option and apply it to your query subsequently.

However, let's say you already managed to implement the functions at SP, you can continue using QueryResult using the same method signature. But, instead of executing the query using db.Context, you call the desired SP and pass the needed parameters manually. Once your query returns, pass the result (should be either IList orIEnumerable) to the Results property of the QueryResult. This should allow the method to be still compatible withe client request, while at the same time enable you to use custom SP call in the server.

Hope this helps.