yes, once you upgrade to 4.4.2, you'll be able to specify a named server filter on alm/qc, and you can put those field specific constraints in the filter itself.

currently, what you have should work, except that all the data comes back to the mf connect service, and the relevant requirements are extracted in memory -

which causes a much bigger performance & data query / extraction hit then if you were to be able to benefit from the server filters.

to satisfy your use case, however, you'd want to use 'equals', not 'contained in string'

Sorry my mistake, it is not a list field but a sting field that's why I'm using the "contained" filter.

What do you mean by ALM/qc? Do you mean that this filter is applicable for ALM projects and other compatibles tools like Jira?

And last question do we have a limit in memory with the 4.4.1?

Because actually I faced several crashed of the server where MF connect is installed ( we have currently synchronised 95000 requirements, 300 epics and 10000 features?

Thanks

Guillaume

Regarding ALM/QC, it is more a performance concern than a scalability one. The impact is strongest when (re-)starting a connection (or when using "Run Once"), after that, change deltas are used. It also depends over how many projects your sync'ed content is distributed.

Nevertheless, server-side filtering (new in 4.4.2, initially for ALM/QC, Octane and ServiceNow) means that the filter is executed on the endpoint system and only the filtered result is transmitted to MF Connect.
In contrast, the mechanism of Sync Criteria is executed by MF Connect on the MF Connect system - meaning it first has to fetch all data to then apply the Sync Criteria filters to it.
The more items you filter out, the more impact as server-side filter will have.

That said, while server-side filters scale and perform better, they also need to be understood well and need to be handled and maintained very carefully!
If you change the filter definition in ALM/QC without considering what it means that MF Connect is also utilizing this filter (to define its scope), then you can create a big mess.
So, while we strongly recommend considering server-side filters, good care needs to be taken that any such filter cannot be changed by other users in an uncontrolled fashion.

Hello Dominique, 

Thanks for this feedback.

Is it something impacting the performances if I use for example 2 to 4 connections with the same octane data source? And for example is it possible to sync requirements from one workspace with 3 other workspaces applying filters (rules)?

Thanks 

Guillaume

Sharing a data source does not impact performance.

And yes, you can implement one-to-many sync scenarios and you use filters and Sync Criteria for that.
Note however, that if you want to sync bi-directionally including the creation of items, then you need to be able to specify/filter very clearly what goes where in either direction. Every project mapping within every connection must be able to determine on its own what is to be sync'ed and what not.