Problem :
Is it possible to change any information pertaining to the stage-names in BPMN work-flow for previous versions or do we need to deploy a new version for such minor changes?
Not really sure, what you mean by "stage names", but every change to the bpmn xml has to go through deployment to be available on the engine.
You don not have to manually create a new version, camunda will just create a new revision based on same key and version for you.
Related
We're using AWS's elasticsearch service. We have a custom synonyms package associated with the elasticsearch domain. The file lives in an s3 bucket, when the file is updated it triggers a lambda that updates the package version in AWS. We followed the documentation at https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/custom-packages.html and so far that all works great for uploading and updating a new version of the package. However, the way aws elasticsearch custom packages work, each domain that uses the custom package stores its own copy of the file as well. To keep search behavior predictable, domains continue to use their current package version until you explicitly update them.
The problem is that I can't find any way to programmatically tell the domain to use the new version of the package. It's like 2 clicks in the console, but I cannot for the life of me find a way to do it from my automation code. The update_package method just updates the package version, it doesn't tell the associated domains to use the new version.
We're looking for a way to programatically tell an AWL elasticsearch domain to update the version of an associated custom synonyms file.
So after banging my head on this for days and I finally figured it out 5 minutes after posting this question. You just need to call the associate_package method again after you update the package. I had actually tried that previously and it failed, but it turns out it fails if there is no new version of the package available. I think I was calling associate_package again before the update_package method was completed, so the new version wasn't available yet.
Anyway, hope this helps someone in the future.
Correct, you have to specifically call associate_package to link to the latest version of that package
Dialogflow has a Versions and Environments BETA. I understand that creating a version captures the current state of your agent. I would like to know if this includes training phrases? When I tried to revert to a different version it did not rollback the changes changes to the training phrases
Secondly, if anyone can answer this question - what is the point of creating a version without publishing?
Quoting the docs:
A version is an immutable copy of the current state of your agent, which you can then publish to an environment. When a new version is created, a snapshot of the intents and entities in your current agent is used.
So it should work, but you would also have to publish an environment. Please note that this is currently a beta feature, so it might have some issues.
Personally I am using option to export agent data to zip file through API and version through this data in a separate repository.
The end result:
After publishing an item, all versions will be visible in the WEB DB, instead of the default behaviour of only having the latest item version.
I'm using Sitecore 8.2.170407
After reading this article, I tried to do several things:
Remove both RemoveOtherVersions and PublishTestingVersions processors by doing a <patch:delete />. That did not work
Add my own patch file, which inherits Sitecore.Publishing.Pipelines.PublishVersion.Processors.RemoveOtherVersions and hides/overrides the base Process method. The new method will do nothing.
Image of patch class and Image of patch config
That didn't work either.
Tried removing the whole <publishVersion> pipeline, but that gave an exception when trying to publish an item.
I've not been able to find a solutions anywhere else. I know a similar question has been asked here, but that was in Sitecore 6
Have any of you been in the same situation before? How did you solve the issue?
If you need more information, please let me know.
Thanks in advance
You can't.
The linked answer you provide is still valid. Sitecore "web" database (any database which is a publishing target) stores one and only one version. To modify this, you're going to need to reinvent your own publishing process.
Based on your clarification, it seems what you want to use is standard Sitecore versioning with specified publish start dates to put up a particular version.
All of the versions would live in your master database, and you would regularly run publishes through the publishing agent or some other means in order to send the appropriate version to the web database on the correct date.
Your authors can preview what the page would look like on a particular date using the date picker in the preview mode.
We have upgraded Sitecore to 7.1, but we are experiencing a problem with publishing.
We create a new item in the master database in English, then we publish this item, switch to the web database to check if it's there, which it is, however... The item does not have a version! Therefore the item is not displaying on the website.
Any ideas as to what could be causing this?
Thanks.
I was having the same issue with Sitecore 8+ where i was able to add language specific content but couldn't publish it. Figured out how to resolve it
1) First Language needs to be registered in \sitecore\system\languages by defining the language to be use.
2) Publish these language items first before publishing content else the behavior will be the same.
3) After publishing languages, then publish the content. In the publish window you will see the language under "Publishing language" section and select the language to publish the content.
Make sure that parent items have a version as well and are also in final state if they are part of a workflow.
I had problems with publishing because I didn't have a language version in one of my parents. In my case it was a parent folder under the content node.
Hope it helps.
Al
Please try republishing your entire site. In some cases, a part of the tree hierarchy might be missing in the Web DB, due to which, publishing the child nodes wouldnt work. Republishing the site can eliminate this chance.
This has been resolved.
It turns out that the SQL server did not have enough space for a full publish. A full publish had been attempted and failed due to the lack of space on the SQL server. subsequently this had corrupted the database.
We had to restore an earlier version of the database and ensure the SQL server had plenty of space for the full publish to finish.
I ran into this issue earlier with my Sitecore 7.2 upgrade. The key here is to ensure the items, templates and layouts (associated with the item) all has appropriate language+versions in master db. In my case, we were also using Partial Language fallback and needed to make that was working proper as well.
Once you identify the item (with missing versions), add them and republish the whole item. For few template types I noticed Sitecore was still not publishing properly. Ex: Items based off Sublayout Folder template. The fix was easy in this case as I changed the template type to Folder and republished.
Also switch to web database in sitecore client and ensure you are able to preview the item (from web db)
Hope this helps.
What is the best / flexible WSO2 upgrade strategy?
Because now we are upgrading WSO2 DSS 3.0.1 to DSS 3.1.1, therefore there is some difficult changes in dbs file one by one
wso2dss-3.0.1
<data name="BASE_PERSON_DataService" serviceNamespace=
"http://company.mn/base/BASE_PERSON">
wso2dss-3.1.1
<data description="multiple services per each table" enableBatchRequests="false"
enableBoxcarring="false" name="BASE_PERSON_DataService"
serviceNamespace="http://company.mn/base/BASE_PERSON" serviceStatus="active">
What is the easy way, we have many data services (dbs files)?
Regards,
Eba
As far as I know, there is usually no standard migration tool or procedure available. Check that the newer version uses a compliant schema for the wso2 registry database and so on; maybe it's the same or you just need to create new additional tables. Sometimes you find things like migration scripts in the dbscripts folder. You should also check for differences in newer xml configuration files, and adjust your older custom configuration to the new format (usually few or no changes could be required). As far as the artifacts are concerned, I never heard of any way to convert them. If there are many of them, I would probably try some script and regex to batch modify and adjust them to the new format.
These are the steps you should follow if you are upgrading
Step 1 - Deploy artifacts {dbs/datasource/drivers}
Cappy the deployed data services from current installation to new installation by copying repository/deployment/server folder.(all dbs files are backword compatible so what ever worked in WSO2 DSS 3.0.1, should work on DSS 3.1.1) Also note you need to copy data source configuration properties if you have created carbon data sources therefore copy master-datasources.xml from repository/conf/datasources to the new installation.
Also Copy all the content of repository/component/lib to the new installation to ensure the the jdbc drivers are properly installed.
Step 2- Change the configuration files
Apply the same changes you have done to configurations files inside OLD_DSS/repository/conf to NEW_DSS/repository/conf (if you have done any such to any configuration files)
Note - If you have done registry mounting make sure you apply to the new installation as done before by changing relevant configuration files such as
carbon.xml,axis2.xml,user-mgt.xml,mgt-transports.xml