Demandware - Pipeline not found for current domain - pipeline

I already made pipeline. Which is working fine. Suddenly it give error like
2015-12-18 02:39:08.091 GMT] ERROR system.core ISH-CORE-2368 Sites-SiteGenesis-Site core Storefront [uuid] [request-id]-0-00 [timestamp] "Error executing pipeline: Hello com.demandware.beehive.core.capi.pipeline.PipelineExecutionException:Pipeline not found (Hello) for current domain (Sites-SiteGenesis-Site)"
Does anybody know how to solve this?

In the event that your pipeline can not be found for the selected domain, please go trough and verify all of the following:
Double check Pipeline-Node naming
Pipeline URLs are generated by their name and your desired entry node, in this scenario, I would expect a file named Hello.xml in you cartridge's pipeline directory, and a start node named Start, would be accessed via {instanceURL}/on/demandware.store/Sites-mySite-Site/Hello-Start
Try and force upload of your cartridges
Occasionally the files on the server will not be updated correctly when a save is made; to force an update, right click your project, click Demandware > Upload Cartridges
Check your Cartridge Path
If you are using a shared instance, or your instance is re-provisioned, you may need to check your cartridge path to be sure your custom cartridge(s) are still there.
Check your Code Versions
Occasionally you may increment / change your code version - if you do, make sure that the path you select in Studio is the one that you have selected in Business Manager.
Tech Support
Should you still have issues following the four steps above, please file a support ticket and the tech-support team will be able to provide you with more assistance.

Related

Invalid config file in clean install - missing configuration section 'contactRepository'

I have done the following:
installed a clean Sitecore 7.5 instance
added the relevant asp.net web forms controls and pages to support the site
imported and published a content tree from an old application
Visiting the base site url yields a YSOD with the error message:
Could not find configuration node: contactRepository
Now I understand what this means - there's an expected configuration section that is missing. Adding an empty element contactRepository yields an expected message that this section is not defined.
What is contactRepository, what is its associated configuration section type, what is it for and what values should be specified in it? Alternatively, how can I turn off whatever demands this section to be present?
edit #1:
In the Sitecore.Analytics.config file in the node there are the following two lines:
<!--This configuration node is obsolete and will be removed in a future version of Sitecore. Use "contactRepository" node to get access to Contact repository-->
<contactRepository ref="contactRepository"/>
The comment is total gibberish. Which node? 'Use' how? 'get access' in what sense? How is this different to what's there?
replacing with an empty <contactRepository> without the ref attribute, commenting out this node, both nodes, and the whole tracking node makes no difference to the application's behaviour.
Looking at my local Sitecore 7.5 setup the Contact Repository settings should be in your Sitecore.Analytics.config.
The contacts repository settings relate to the new xDB stuff.
Please ensure you have the correct Sitecore.Analytics config files for 7.5.
There should be around 15 config files with new settings for xDB.
Please read this blog post for more information on the new Analytics setup.
https://www.sitecore.net/learn/blogs/technical-blogs/getting-to-know-sitecore/posts/2014/10/introducing-the-sitecore-analytics-index

Rules requiring manual run in Alfresco

I have a rule on a folder which executes a JavaScript code whenever a new document enters the folder. The issue is the rule doesn't run automatically when a document enters the folder, but I have to run it manually.
I have tried running the script in background too. If I put a rule on update, that works automatically. The problem is with creation or entering of new documents in the folder. I am using Alfresco community 4.2.f share.
Please advise.
Thanks.
I cannot recreate this problem in Alfresco Community Edition 4.2.f. Make sure that:
All of the rules are enabled
The person putting the document in folder1 has permissions to create new documents in Folder 2.
The criteria for the rules are valid
The script in Folder 2 is not actually running. The best way to validate this is by turning on the server-side JavaScript debugger by editing $TOMCAT_HOME/webapps/alfresco/WEB-INF/classes/log4j.properties and setting log4j.logger.org.alfresco.repo.web.scripts.AlfrescoRhinoScriptDebugger=on
Alternatively, for #4, you could change to an out-of-the-box action, like another Move that would move the document to Folder 3. That's what my test does. If that works for you like it does for me, you would be able to narrow down your troubleshooting to a problem with the custom script.
when running scripts fired by rules you can't rely on search for the new doc since indexing isn't finished when the script runs. If SOLR is configured as search engine, indexing is executed async from outside the repository every 15 secs. You already may know that you can get the name from the script node?

GET and .xq files

When using exist-db, a GET message will obtain an entire file from a collection (by providing the URI). In the case of a .xq file, however, the same GET message will instead execute the file.
I am wondering if there is anything I can attach to a GET message to cause exist-db to return the file rather than execute it. I should have all the necessary permissions, or I should be able to set them.
Thank you.
Assuming you are running eXist as a stand-alone server:
"GET accepts the following request parameters, which must be URL-encoded" _source=yes | no - which "Specifies whether the query should display its source code instead of being executed" - see the developers guide online for full details & example usage.
eXist sets this capability to 'no' as default in it's config - however you can override this permanently by adding specific files to the <allow-source></allow-source> section in the Web-application Descriptor file (descriptor.xml) read from WEB-INF directory of the web application or from the directory specified by the exist.home system property.
Hope that helps.

Alfresco: Backup and Restore Issue

I followed Backup and restore method in alfresco share instead of import/export. It is now working as i expected in new Alfresco, i can see the content in sites, can view files in site document library, can view events, workflow,users,groups and so on. Everything goes fine except that the repository is not loading, but When i search for files in repository it is showing "3 result(s) found in Quality site."...but it is not displaying those files.
In my old Alfresco i have set permissions for folders in repository...will it cause any error to load repository in my new alfresco?
It shows following error when i close my server...
log4j:ERROR LogMananger.repositorySelector was null likely due to error in class reloading, using NOPLoggerRepository.
Kindly look into my issue and give some suggestion......
that error means that the log4j tries to log something in the log file of the webapp but Tomcat already shut down. have you sufficient/right permissions on the new restored alfresco installation?
If you followed correctly the backup/restore procedure from the wiki, the permissions on nodes of the repository also come together. But, if you want to reset and rebuild all the permission, you could perform a FULL reindex with the string appended to alfresco.global.properties:
index.recovery.mode=FULL

Culture name is not supported

I'm receiving "culture name 'uploads' is not supported" when my ASP.NET application start. Where do I have to view/debug to toggle the error?
A full-text search for "uploads" returns 0 entries in my project.
I've deleted this folder and it solved the problem:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\8dfb04ef\44bf70fb\uploads
Do not worry, it is not a real error.
When the runtime tries to find which resource assemblies exists, it tries to enumerate folders where compiled DLL files reside. It assumes the name of the folder is the culture name, so it tries to create a culture for it. Unfortunately uploads is a folder which is created automatically by ASP.NET, and it is obviously not a culture :).
The runtime ignores some predefined folders like "hash", but not "uploads". So we have to live with it.
I am getting the exact same error. ["culture name 'uploads' is not supported"]. I do not know what is causing it but I've been able to get around it by clicking [Debug|Exceptions (Ctrl-alt-E) and un-checking "Common Language Runtime Exceptions". I do not have an 'uploads' folder or file in my project and there is nothing in my project that has anything to do with multilingual support and the error fires right off the bat when I run my project ... looking at the call stack just walks me through a whole lot of mscorlib calls. I have no clue why it's even getting called.
JumpingLethalRampage, instead of unchecking all "Commong Language Runtime Exceptions," you could uncheck just "Common Language Runtime Exceptions > System > System.ArgumentException." You don't need to uncheck all CLR items.
It sounds like maybe you have some code somewhere that is trying to set the culture based on a URL pattern (this may be tracked down if it is possible to get a stack trace). For example, sometimes I'll set up multi-lingual sites with URLs like this:
http://www.example.com/en-US/
http://www.example.com/es-MX/
I'll then have code in my base page that looks at the URL and attempts to set the culture based on the URL path. But if you tried to hit a URL like:
http://www.example.com/uploads
It would fail with an error like what you are seeing if you just blindly take the first path element and try to use it as the culture without checking it first.
If the application is it built upon DotNetNuke (and not a simple ASP.NET application), this kind of error generally occurs in DotNetNuke due to the issue described in Culture name '__page' is not supported.
If you are not using DotNetNuke, check your Application_Start code (in the Global.asax file). It might be setting the CultureInfo. Or check your web.config file for any invalid culture values.
Assuming that your search through the project wasn't restrictive (widest possible search in all files), then my guess would be that your browser has a User language set to a custom string - "uploads".
In IE, you can check via Tools -> Options -> Languages -> Add -> User defined language.

Resources