E Commerce Script

[Bartie Spalitto]

Im having this strange error message while trying to start Commerce Manager site: Failed to execute script because validation failed: 'Not an EPiServer CMS database'. On the CMS side everything seems to work as expected. Am I missing something obvious here?

It looks like there are some SQL upgrade scripts on the CMS database for the Commerce packages that check if the tblContentType table exists, otherwise spits out that error message. Perhaps double check the connection string, making sure it's the same CMS database the CMS site is using. Or use SQL Profiler when getting this message, to see what query gives the error and debug further from there.

This is a fresh installation and I did move the local databases to server, but I didn't know Commerce Manager does have it's own connection strings and I didn't update those to use DBs on the server...

Most probably you'll need to set them up manually or hire a developer. Actually, you'd want to hire a developer because someone needs to support that. It's very risky to host eCommerce websites because you need to keep everything working and up-to-date to avoid security issues.

So, you can do this a couple of ways, but first you should understand that it's going to be either extremely simple, or extraordinarily painful. Evaluating these systems is near impossible until you have actually had to build a few of them out. I have come to hate pre-built, all in one e-commerce solutions a bit. It's not the basics of handling the transaction that get messy - they all do that simple task extremely well - it's all the complexities of different regions, associated taxes, unpredictable business rules, and odd shipping schemes that make these projects tough. Think about doing business in Europe. Now you have to account for all kinds of rules applying to the Value Added Tax, and these kinds of rules are not uniform from country to country. In the US, state and local taxes might apply. Knowing this, and when to charge x or y is what makes e-commerce painful. You should also take into consideration the market / industry of the client - the rules and norms vary from industry to industry.

Drupal is a good option if you need to scale for high traffic, needto be able to manage a lot of different user roles for varying levelsof access, etc. Drupal is also the best option for people who don'twant to learn programming but still would like to be able to do justabout everything a programmer can do.

Drupal Commerce has a learning curve, but it is definitely a verycapable system if you are willing to take it on. Just make sure tounderstand the difference between products and product displays, andwhy they are treated separately in Commerce. It can be annoying, andis one of my biggest pet peeves about Commerce, but for certain kindsof products (products like a tee-shirt that comes in 5 sizes and 7colors - you create a product for each, and attach them all to asingle product display.

Drupal's biggest downside is the extensive learning curve -ESPECIALLY with Drupal 7 and the Drupal Commerce module system.Depending on your needs, you might want to go with Drupal 6 andUbercart. Also, to build a custom template may require a little bitof php.

Wordpress: It's super easy and flexible. You need minimaltime to train your end-users, but the e-commerce solutions I haveseen so far are weak, though it has been a year since I haveevaluated it for this landscape. There may be a lot of great toolsout there that have developed since then. If you can find a trulyrobust e-commerce plugin system for wordpress (it may cost $99 orso), you might want to give it a spin. The learning curve forwordpress is significantly lower, but the e-commerce plugins were lackingthe last time I tried to use it for e-commerce (it required a lot of customdevelopment).

The second option is to get an open source solution that is designed for e-commerce from the ground up. I think this is a better way to go about things if the site doesn't have complex needs for content publishing, role management, etc. If you do have these needs, Drupal is an outstanding solution (as long as you have a little patience).

The next thing to consider is how to process your credit card transactions. I prefer Authorize.net for a number of reasons - the client pays for this, and it serves as the background credit card processor on your site. You're not a bank, and you never ever ever want a solution that stores credit card transactions within the app. You can get into a LOT of trouble doing this if you aren't certified to store private credit card data - and it will cost a fortune to do that. So, use authnet.

One important final note: - If any of your projects need to allow for recurring payments (ie regular monthly / automatic cc transactions) , you need to understand that this is easier said than done. For reoccurring payments to work, credit card information MUST be stored somewhere. If this is required, you want a system that can interface with authorize.net's automatic / recurring payment API, and NOT one that stores credit card information locally. At the moment (to my knowledge), the ubercart and Drupal Commerce solutions are lacking, but they are trying to get it to work with a service called recurly

"Most probably you'll need to set them up manually or hire a developer. Actually, you'd want to hire a developer because someone needs to support that. It's very risky to host eCommerce websites because you need to keep everything working and up-to-date to avoid security issues.

(for some reason I couldn't add a comment) I don't necessarily think this is correct. If you are doing e-commerce correctly, the secure transactions are all being handled by the third party payment procesor (this is what Authorize.net does, as well as other services). The script should NEVER store any kind of private data like credit card information. For that to work, you need a DSS PCI certification, and you have a lot of expensive work ahead of you to get to that point. So, instead, you should use a payment gateway that separates the layers requiring secure transactions and the layers used for browsing / shopping / cart / etc.

Only existing customers can access some of the links on this page. Visit Salesforce Commerce Cloud GitHub Repositories and Access for information about how to get access to the Commerce Cloud repositories.

Attributes that are queryable can be found when using Advanced Search extended attributes when searching for products in Business Manager. Whether or not the data type is queryable in Business Manager doesn't affect whether the attribute is searchable in the storefront.

Scripts in different contexts can have different timeouts (see the following tables). If a script is called from a different context then the resulting timeout is the one that ends earliest. For example, if shortly before the 5-minute timeout of a controller request a page designer script is started, then the page designer script can be aborted before its own 30-second timeout is finished.

Typically this error leads to an error response (HTTP status 500) or a failed job execution. Note if this happens during template rendering the request might not fail, instead, a partly rendered response might be seen by users, but such responses are never cached longer than 5 minutes.

The timeout values for SFTPClient, HTTPClient, and webreference objects are based on the timeout value of the calling script. The script timeout value is used as an upper bound for the timeout that is configured for the SFTPClient and HTTPClient.

Starting in 13.6, B2C Commerce supports the Modules 1.1.1 CommonJS specification. Script modules within your storefront code can be located in cartridges. But unlike traditional B2C Commerce script files, the script modules within your storefront script code don't have to be located in cartridges.

A CommonJS-compliant B2C Commerce script module is either a script file (with a .js, .json, or .ds extension) or a directory containing script files. A module can hide private data, while exposing public objects and methods via a free variable named exports.

Before 13.6, you had to use the importScript and importPackage methods to access other scripts; these methods automatically export everything into the global context. Now you can access CommonJS-compliant modules using the require method. These modules don't automatically export everything into the global context.

Within a script file, you load a CommonJS-compliant B2C Commerce script module using the TopLevel.global.require(path:String) method. When the module is loaded, you can use any of its exported variables or methods.

If the path argument starts with "./" or "../", then it loads relative to the current module. The module can be a file or a directory. A file extension is acknowledged, but not required. If it's a directory, a package.json or a main file is expected in the directory.

If the TopLevel.global.require(path:String) method is used to reference a file, an optional file extension is used to determine the content of the file. Currently, B2C Commerce supports the following extensions, listed in priority order:

Although Salesforce provides a sophisticated fallback mechanism for scripts in the global namespace, we generally discourage polluting the global namespace with utility scripts. We recommend adding scripts to specific project cartridges.

Web analytics are an essential tool when you want to understand how your customers interact with your site and make decisions that will help optimize the experience for maximum conversion. Many web analytics packages are available to help you achieve these goals, such as Google Analytics, Clicky, Moz Analytics, and KISSMetrics. Most web analytics packages require that you add client-side script code in the element of the HTML for all pages of your site.

If content security policy (CSP) is enabled for your site, ensure that all external URLs are added to the script-src CSP directive in Commerce site builder. For more information, see Manage Content Security Policy (CSP).

3a8082e126