Release notes for Optimizely CMS and Customized Commerce updates

Forms Service API is supported on .NET 6.

Try to install following NuGet packages in a same project:

• EPiServer.ContentDeliveryApi.Search
• EPiServer.Forms.ServiceApi

The issue is that both has a dependency of another NuGet package (Microsoft.AspNet.OData) but to different versions. EPiServer.ContentDeliveryApi.Search needs Microsoft.AspNet.OData between 6.0.0 - 7.0.0, whereas EPiServer.Forms.ServiceApi needs Microsoft.AspNet.OData between 5.6.0 - 6.0.0, making it almost impossible to install both NuGet packages in same project.

To improve performance, this version introduces a new endpoint for retrieving submission data.

/EPiServer.Forms.ServiceApi/FormSubmission/

Supported query parameters:

• language: Language of form (ISO 2 Letter Language Codes. For example: en, sv)
• skip: Index of the first submission to return.
• top: Maximum number of submissions to return.
• sortColumnName: Sort results by column name. (e.g. __field_123).
• sortDescending: Sort direction. Default value is true (sort desc by default if no param is passed).
• beginDate: Show submission created after date.(format: 2014-04-25T16:15:47-04:00) (ISO 8601 format).
• endDate: Show submission created before date.(format: 2014-04-25T16:15:47-04:00) (ISO 8601 format).

• FormServiceApi retrieves all data submission from database before OData is applied.
• We should introduce new endpoint for retrieving submission data and data should be filtered/paginated at database layer. That endpoint is described in AFORM-2406.

Steps to reproduce

1. Install a site with Forms.
2. Install Episerver.serviceapi 5.0.
3. Install Episerver.forms.ServiceAPI .

--> Error: Episerver.ServiceAPI 5.0.0 not compatible with Episerver.Forms.ServiceApi 3.3.0

Forms.ServiceApi should depend on Forms.Core only. Before this change, it depended on the Forms package.

This story introduces a new method for deleting form submissions: DeleteFormData.
The method requires formId (int) and recordIds (array of string) as its parameters.

Note: To perform the DeleteFormData method, the user must have WriteAccess permission to access the EPiServerServiceApi.

1. Create a new epi site like Alloy.
2. Create a custom WebApi controller using attribute routing and test that it is working correctly.
3. Add Epi Forms and EPiServer.Forms.ServiceApi to the solution.
4. Add files to the solution

Result:

If enabling episerver:serviceapi:maphttpattributeroutes, you get this error: A route named 'MS_attributerouteWebApi' is already in the route collection. Parameter name: name.
http://screencast.com/t/R4caDTYk

If disabling it, you get this error: ValueFactory attempted to access the Value property of this instance.
http://screencast.com/t/t5qB4AFgH6P

See full thead in https://www.yammer.com/emvp/#/threads/show?threadId=683701526&messageId=684742307

Suggestion from EMVP:
Installing this however gives an error, more specifically that that the attribute routing is already configured. So am I missing something here or should the mapping of the httpattributes not be done in the forms api, as it is already done in the service api, on which it depends?

If I disable the mapping for the service api in the app settings, the error is gone and the mapping still done. Which is a fix, but I don't think I should have to?

I see the instruction to set "episerver:serviceapi:maphttpattributeroutes" to false. But why should I have to do that? The forms api depends on the service api, so the attribute routing would have been mapped already, right? There is no need for the forms api to do it as well? It might also cause a problem if other modules want to register attribute routing and you cannot disable it for the forms api as well?