New simple batch saving API for Commerce
In Commerce 13.8, we introduced a new, simple batch saving API for catalog content. If you want to try it out, look into new extension method of IContentRepository, resides in
EPiServer.Commerce.Extensions. There is a new method called "Publish", which allows you to publish multiple catalog content at once. This is an example of updating all language versions of a content.
var languageBranches = ContentRepository.GetLanguageBranches<VariationContent>(content.ContentLink);
var list = new List<VariationContent>();
foreach (var languageBranch in languageBranches)
{
var writable = languageBranch.CreateWritableClone<VariationContent>();
writable.Name += "updated";
writable.DisplayName += "updated";
list.Add(writable);
}
ContentRepository.Publish(list);Publish can take language versions of a content, multiple content with same language, or a combination of both.
It's important to keep this mind that this method skips certain things for the optimal speed. As in the remarks, "This method bypasses the content publishing pipeline and therefore does not validate for error, nor fire content level events, nor handle versions. It does not create new versions, but commits data in the contents to the published versions.". The low level events, however will still be fired.
You might ask what would be the use cases of the new API. Well, this new API is simple, and it acts as a shell for Catalog import export. You can achive almost the same result (with somewhat better performance) with CatalogImportExport. However, the big drawback of CatalogImportExport is that you need to have the XML - either from a PIM connector, or build it yourself, which is not the most hassle-free task in the world. If you already have code to build your catalog content instances, you can use this API to "publish" your change.
A new improvement which allows you to sync draft is coming in Commerce 13.9. A new overload which takes a PublishAction (new enum) parameter is added, if you choose PublishAction.SyncDraft, it will sync the changes to the versions, so you can see changes there as well.
Note that this API is still marked as BETA. As usual, BETA means tested, but we reserve the right to make changes to the APIs without notice/major versions. That also means your feedback and suggestions can be implemented sooner than usual.
Nice! Looking forward to test this :)
It will be great if that supports import digital assets too
I'm receiving this exception when trying to modify assets, so I second what Raed just wrote.
System.Data.DeletedRowInaccessibleException: Deleted row information cannot be accessed through the row. at System.Data.DataRow.GetDefaultRecord() at System.Data.DataRow.get_Item(DataColumn column) at Mediachase.Commerce.Catalog.Dto.CatalogEntryDto.CatalogItemAssetRow.get_CatalogEntryId() at Mediachase.Commerce.Assets.Database.AssetServiceDatabase.<>c__DisplayClass4_0.<CommitAssets>b__0(CatalogItemAssetRow x) at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext() at Mediachase.Commerce.Assets.Database.AssetServiceDatabase.CommitAssets(IEnumerable`1 updatingRows, CatalogEntryDto entryDto, Int32 entryId) at EPiServer.Commerce.Catalog.Provider.Persistence.EntryContentBaseCommitter.CommitAssets(EntryContentBase content, CatalogEntryDto entry, Int32 entryId) at EPiServer.Commerce.Catalog.Provider.Persistence.EntryContentBaseCommitter.UpdateExisting(IEnumerable`1 contents, Boolean syncDraft) at EPiServer.Commerce.Catalog.Provider.Persistence.EntryContentBaseCommitter.Save(IEnumerable`1 contents) at EPiServer.Commerce.Extensions.IContentRepositoryExtensions.Publish(IContentRepository contentRepository, IEnumerable`1 contents)
@Raed @Johan I will look into that.
Are you trying to delete the asset? What code did you use?
@Quan I will let @Johan answer above question regarding the error. From my end currently we are using EPI Service API to sync catalog and assets and my point was does the new API support importing assets as we need both typically when we push data into Episerver (i.e. from a PIM)
Yes, just did a simple writeable.CommerceMediaCollection.RemoveAt(i);.
Thanks. I will add a fix for that in 13.9
Nice, this would simplify our import process.
@Quan, is there a recommended max nr of items for a batch?
@Mari: I did some test and 200 per batch is marginally faster than 100 per batch. But YMMV. You can always start with 20.
Ok, so I have played around with this for a while.
After spending 2-3 hours thinking I had a bug in my code, I realized the issue was the following:
Changes applied on objects using .Publish() are not reflected in the Catalog UI. If I query the database, I can see my changes.
So, is this a bug or "by design" (i.e. cached for a while)?
@Mari you probably are not using 13.10 and the Publish(contents, PublishAction.SyncDraft)?
I am on version 13.9, so that is correct.
Just to be clear you can use the overload on 13.9, however we recommend to use 13.10 as it's already out and has some bugs fixed.
Finally got around to upgrade to 13.10 and test the api again. I can confirm that bug is fixed, and it seems a bit faster than 13.9. Great stuff!
Update: there are 2 bugs in play related to batch api. Could be nice to know about:
https://world.episerver.com/support/bug-list/bug/COM-10634 and
https://world.episerver.com/support/Bug-list/bug/COM-10609
Hi,
"This method bypasses the content publishing pipeline and therefore does not validate for error, nor fire content level events, nor handle versions. It does not create new versions, but commits data in the contents to the published versions"
Does it invalidate native related cache entries and triggers a find index of said changed item?
The low level events are still fired, and the cache are still be validated properly. If you don't disable Find Commerce event indexing then everything should work as usual