We are facing a challenge, with regards to MATMAS publication.
At some instances, we could see the somepart canonical items are missing to get published, means(Impex's) are not getting generated.
Is there a way to debug where exactly the datahub cannonical item convert to target items. So that we can revalidate what are items are going to be generated in the target publication and what are missing
Note: We can see AsynchronousEventPublicationService which is taking all the events and publishing to target items, but that is not helping to find the exact source of the method initiator while debugging OOTB Datahub Code.
Related
I'm aware that Hybris have savedvaluesmodel and savedvalueentrymodel to capture last changes of the data model and its attribute value whatever has changed recently, and it also maintains the history.
And this works only if we are modifying the data after login into Backoffice and this doesn't seem to work in case of feeds which comes via HotFolder. I'd like to know, is there any provision which comes with Hybris out of the box to capture the same information or changes that was done for a given data model through feed?
What I have observed based on OOTB code is ,this class DefaultItemModificationHistoryService is responsible for logging the changes (populate the values and saved the last changes into the saved values model table) that was done at the model level, and this is located inside the OOTB Backoffice extension and this extension is already extended by myprojectbakcoffice extension which further extends myprojectcore extension.
In order to capture the last changes done via feed we thought of handling that logic in an interceptor, however the above class isn't accessible in our myprojectcore extension as it's declared in Backoffice.
What are the other possible solutions that I can think of in order to implement this?
Found some article related to this in here.
Please advise.
You can use the hybris commerce audit framework to log all of the changes happening in the system.
The documentation here says, "Generic audit tracks every persistence action, including creation, modification, and deletion for specified types. The audit is stored as a change log that allows you to see how an item changed over time."
But this comes with a DB overhead. There are specific tables that gets heavily logged with the details of the changes.
These tables have a naming convention as <item_type>_sn.
E.g.: For Order item type, the audit table would be auto created as orders_sn
This is why it is always advisable to turn off the audit as applicable.
For some unknown reason, during the checkout flow a global message error appears saying Item no longer valid (was removed) - Object no longer valid
when we check its the item is a cart entry which is no longer valid
we found a similar issue raised in git hub. Below is the GitHub issue link,
https://github.com/SAP/spartacus/issues/5596
We wanted to know if any solution was discovered for this issue
We have below versions,
Hybris - 1905.7
Spartacus - 1.4.4
This is a known case with multi-dimensional products.
Generic variant product is dependent upon the Product as a partOf attribute. But in some scenarios when the GenericVariant product instance is modified without modifying the base product then sync deems that genericvariant instance as an orphaned one that should not be related to the product so it deletes the variant and recreates one.
Now in the checkout, the PK of the entry changes as the sync has created a new Online variant due to the above reason. Since the cart contains the entry of the earlier variant with another PK which could not be found, the error of "Object No Longer Valid" is thrown.
This is not traceable as the same product is available in the cart entry (but with a different PK)
The below approach of modifying the sync description through Backoffice-> System -> Multithreaded Synchronization should help to resolve this.
In the below screen, I have disabled sync of Product Variants [Variants] (The selected node). By default, it is ticked.
CX Jira References:
https://cxjira.sap.com/browse/ECP-3394
https://cxjira.sap.com/browse/ECP-5494
I believe this is also related or very similar to the backend, which throws the error type 'JaloObjectNoLongerValidError'
For Spartacus release 5.0, which should be coming somewhere in March 2022, we have fixed this issue by creating a backoff mechanism, which retries the request when the error is thrown.
An example of it's usage can be found in here.
Moreover, you can see the mechanism in action from this end to end test.
Not able to sync content page when i changed the approval status to unapproved.
I reverted back it to "Approved" still page not getting synced.
I compared the dumps in sync job , it's exactly same.
What could be causing the issue?
Troubleshooting the synchronization is very complicated...
A synchronization is executed using a synchronization cronjob. To find the respective cronjob:
go to hmc/backoffice
navigate to System/Cronjobs in hmc or System/Background Processes/Cronjobs in backoffice
use the types dropdown to restrict the search to "Multithreaded Synchronization"
pick the most recent one OR look in log file for this output and search for the code.
INFO [Thread-107] (000000RS) [CatalogVersionSyncJob] Sync 'sync powertoolsContentCatalog:Staged->Online' (pk:8796094464500) configured 0 entries for job '000000RS' (pk:8796125823477) schedule medias: 1
This is the cronjob that executed your synchronization. Now it is getting even more tricky:
go to the administration tab
look for an attribute called "Dump medias"
download the media file where attribute Realfilename starts with "sync_dump_"
The downloaded file should contain comma seperated values.
Example:
8796256994364;8796256961596;;actions,allDocuments,...,uid,urlLink,visible;;false
The entries represent the following data:
the PK of the source item
the PK of the target item
(timestamp)
a list of attributes, that could not be synchronized
?
item has been victim to a deadlock
Now you can troubleshoot your synchronization by evaluating source and target items and pending attributes.
Sometimes there is a problem when referencing an item, that does not exist in the target catalog, sometimes a uid is already existing in the target catalog. Sometimes an initial attribute needs change. There are a lot of pitfalls. In this case you can try to use this property to get more details about the exception that is thrown during sync:
synchronization.itemcopycreator.stacktraces=true
Here is some additional information:
https://www.sap.com/cxworks/article/2589632280/catalog_synchronization#CatalogSynchronization-TroubleshootingFailure
I have a some product. I want to add a link of this product in different category, but i need to known when a link was created.
I have a collection of links(CurrentDocument.Links) of this product, but i need to known time when some link was created.
How to get difference of links if I get these links with help CMS.DocumentEngine.TreeNode CurrentDocument.Links
Would you please provide more information regarding your problem. Some code would be great.
However, if you are getting links with TreeNode help you can use DocumentCreatedWhen property to get the date and time when the document was created.
I used some of the Hybris reserved Deployment code and then later changed to non-reserved deployment type codes. Do I need to Initialize the system in-order to reflect the changes with new deployment code or just an Update works. There are many items that deployment code has been changed. Why update doesn't work?
When you use a reserved code in your deployment table, you're likely to add the attributes of your object in an existing table. If you have attributes with the same name, it'll surely be a mess in the table (I don't know how hybris will choose the table type for example).
When you run an update with the good deployment code, it will create a new table which is just fine. The other table which has been used by two objects will still remain potentially broken because hybris won't delete any column.
That's why you should initialize your system to have a clean DB. The issue is that you'll lose all your data.
If you need to migrate data it will be probably quite hard because you must have to look on the broken table and distinguish between the attributes that should not be there and the others. So I hope for you that it's just a dev issue!
Actually i would suggest you to do initialize rather than update more likely that the update will not work for you in this case and probably you will get some error messages saying invalid pk xxxxxxxxxxxx because of unknown typecode yyyy.
As you may know the typeCode (deployment code) is an essential operator for the generation process of PKs in Hybris and thanks to it Hybris can ensure the uniquenessity of the PKs, so even if you change the old typeCode with a new one it's very likely that Hybris will still keep the old typeCode somewhere hence PKs already generated will never be consistent with the new typeCode.
So that's why you should never change the typecode of an item once given.
My suggestion is :
To make a backup of your existing data (you can export it from HMC,
you may take a look at alain.janinm's answer here).
Then initialize your System.
Then re-import the data again.
Note : that typecodes between 0 and 10000 are already reserved for hybris
particular items.