In shopify if I create a new store I get my own admin panel. I am going through nopcommerce and it appears to me that a single installation is built for only one shop admin. So if I am running nopcommerce from my site I can not let users register and create new stores - I could run 1 store though?
Is this understanding correct or nopcommerce lets users register and create new shops?
I think you're misunderstanding nopCommerce. It's not a SaaS platform like Shopify, but a full on-site installation of an ecommerce application.
In recent versions, you can manage more than 1 store with the same installation, so that different domains point to different stores. However, in my opinion this is intended to have different shops under the same owner, so you don't have to set up another server/hosting plan for each shop you want to run.
When having multiple stores, you can assign products, categories and so to a specific store.
See more information at http://www.nopcommerce.com/featurelist.aspx
Quote from above:
With multi-store support you can launch several online stores using a single integrated system. You can create unique online stores for multiple brands, products, B2B, B2C, affiliates, co-branded stores and more. You can also quickly launch micro-stores for promotional campaigns. Best of all, every online store shares a single database.
Related
I have a requirement where my company CEO bought three more companies and now became 4 companies. Every company has its own Active Directory and they are on different locations within a city. How would I use different AD's for SharePoint? What kinda network do we need to bring so all companies can access SharePoint from there locations? etc
Got a requirement to implement SharePoint so all companies can work in collaborative manner and get alerts using email as well. Can anyone let me know what needs to be done in a proper sequence manner.
1?
2?
3?
I would really appreciate your help.
We have different instances of websites some of them with up to 4 multisites each. They have their own XDB backend.
We have a requirement below:
Able to track the user between each sites. When user visits the dental site and comes to company main site then show the carousel
banner with dental Ads.
When user fills up the form or download certain PDF documents, increase the accumulated goals. e.g. if user visits dental site and
fills up form (worth 10 points) and goes to different site and
downloads pdf (worth 5 points). The total goal value accumulated
should be 15.
Should be able to view the exact same user profile details (on each instances).
I understand we could use Federated experience manager, but above all are sitecore instances.
Would you able to help us how above can be achieved?
e.g.
Do we need to share same xDB and analytics Databases for ALL INSTANCES?
Does all sites need to be on SINGLE instance to achieve above?
Is it possible to share goals, personas, segments setup between different instances?
Any other recommendations?
Finally how does sitecore works out the predictive personalization i.e. it reads the xDB or analytics or something else?
Thanks.
Do we need to share same xDB and analytics Databases for ALL
INSTANCES? Yes.
Does all sites need to be on SINGLE instance to achieve
above? All sites can exist on separate instances, not an issue here.
Is it possible to share goals, personas, segments setup
between different instances? Yes share the xDB among the instance, setup Database replication in CD and make sure machine key are same Please note that there lot of other things to be considered for coming to conclusion on this point.
More reference links:
http://digital-learnings.blogspot.in/2015/12/sitecore-multi-site-or-multi-instance.html
https://doc.sitecore.net/sitecore_experience_platform/developing/xdb_overview/scalability_options
http://www.nonlinearcreations.com/Digital/how-we-think/whitepapers/Whitepaper-Planning-your-Sitecore-xDB-infrastructure.aspx
Consider the following micro services for an online store project:
Users Service keeps account data about the store's users (including first name, last name, email address, etc')
Purchase Service keeps track of details about user's purchases.
Each service provides a UI for viewing and managing it's relevant entities.
The Purchase Service index page lists purchases. Each purchase item should have the following fields:
id, full name of purchasing user, purchased item title and price.
Furthermore, as part of the index page, I'd like to have a search box to let the store manager search purchases by purchasing user name.
It is not clear to me how to get back data which the Purchase Service does not hold - for example: a user's full name.
The problem gets worse when trying to do more complicated things like search purchases by purchasing user name.
I figured that I can obviously solve this by syncing users between the two services by broadcasting some sort of event on user creation (and saving only the relevant user properties on the Purchase Service end). That's far from ideal in my perspective. How do you deal with this when you have millions of users? would you create millions of records in each service which consumes users data?
Another obvious option is exposing an API at the Users Service end which brings back user details based on given ids. That means that every page load in the Purchase Service, I'll have to make a call to the Users Service in order to get the right user names. Not ideal, but I can live with it.
What about implementing a purchase search based on user name? Well I can always expose another API endpoint at the Users Service end which receives the query term, perform a text search over user names in the Users Service, and then return all user details which match the criteria. At the Purchase Service, map the relevant ids back to the right names and show them in the page. This approach is not ideal either.
Am I missing something? Is there another approach for implementing the above? Maybe the fact that I'm facing this issue is sort of a code smell? would love to hear other solutions.
This seems to be a very common and central question when moving into microservices. I wish there was a good answer for that :-)
About the suggested pattern already mentioned here, I would use the term Data Denormalization rather than Polyglot Persistence, as it doesn't necessarily needs to be in different persistence technologies. The point is that each service handles its own data. And yes, you have data duplication and you usually need some kind of event bus to share data across services.
There's another option, which is a sort of a take on the first - making the search itself as a separate service.
So in your example, you have the User service for managing users. The Purchases services manages purchases. Each handles its own data and only the data it needs (so, for instance, the Purchases service doesn't really need the user name, only the ID). And you have a third service - the Search Service - that consumes data produced by other services, and creates a search "view" from the combined data.
It's totally fine to keep appropriate data in different databases, it's called Polyglot Persistence. Yes, you would like to keep user data and data about purchases separately and use message queue for sync. Millions of users seems fine to me, it's scalability, not design issue ;-)
In case of search - you probably want to search more than just username, right? So, if you use message queue to update data between services you can also easily route this data to ElasticSearch, for example. And from ElasticSearch perspective it doesn't really matter what field to index - username or product title.
I usually use both approaches. Sometimes i have another service which is sitting on top on x other services and combines the data. I don't really like this approach because it is causing dependencies and coupling between services. So in general, within my last projects we tried to stick to polyglot persistence.
Also think about, if you need to have x sub http requests for combining data in some kind of middleware service, it will lead you to higher latency. We always try to cut down the amount of requests for one task and handle everything what is possible through asynchronous queues. ( especially data sync )
If you conceptualize modules as the owners and controllers of the data they work on, then your model must also communicate that data out of that module to others. In contrast, the modules in a manufacturing process have the access to change data without possessing and controlling it.
Microservices is an architecture for distributed processing, like most code, where modules pass the data around to work on it. From classic articles by Harvard Business Review and McKinsey on the subject of owning members of a supply chain, I identified complexities arising from this model and wrote an article teaching programmers what you need to know: http://www.powersemantics.com/p.html
Manufacturing is an architecture for integrated processing, where modules work on the data without passing it around from point to point. This can be accomplished by having modules configured to access the same memory, files or database tables. My architecture shows how to accomplish this on memory via reference properties.
When you consider "exposing an API at the Users Service end which brings back user details based on given ids", you need to be aware that creates what HBR calls "irreversible" complexity, which I've dubbed centralization complexity. Don't build A->B (distributed) systems, because you can't decentralize them later after failing to separate requirements. Requirements in production processes represent user instructions, and centralized modules only enable you to change the wrong users' processes. In other words, centralized modules don't document user groups or distinguish them from derived-product-users.
I've been playing around with an idea for an amazon store with Drupal 7. I do a lot of product reviews, and I typically link to amazon pages already (without referrer IDs, since I wanted toa void any questions of integrity all together), but having a seperate storefront link, well I'm playing with the idea.
I'm using Drupal 7, and I installed the Amazon API and Amazon Store module. It uses an Amazon AWS account and amazon associates ID. Basically creates a light storefront that does all the lifting through amazon itself. It only even uses Amazon items, which is fine since what isn't on Amazon, and only gives you a referral payout.
Well, what I'd love to do is have a stronger control over the items in the store. The Amazon Store module just gives you the option to control the basic items that are visible upon loading.
What I'd like to do: Create a store where categories match the contents of my site, and disable the search options. Is this possible with these modules? Does anyone have advice on creating something like this?
please see the below module and I hope it will be handy
https://drupal.org/project/amazon_store
We have two ColdFusion applications that share a common database. There are three instances of each application. (One instance of each application runs on each of three servers.)
I can see that the three instances of a given application should share a client variable store. (Load-balancing can cause a single user session to bounce between the three instances.) My question is: Is there any danger to having all instances of both applications share the same data store? Or should only one application be pointing at a given data store?
You can use the same client data store. The CDATA table has an 'app' column that stores the coldfusion application name. That column will keep your data unique to each application.
I'm working at an enterprise level ColdFusion shop with multiple CF applications running on the same server that are all pointed at the same client variable store. The only concern within the organization is how the client variable store affects regular backups, and that falls under the data team's purview. We don't have any problems with the different apps actually using the same client variable storage.
Related, from the ColdFusion documentation:
Some browsers allow only 20 cookies to
be set from a particular host.
ColdFusion uses two of these cookies
for the CFID and CFToken identifiers,
and also creates a cookie named
cfglobals to hold global data about
the client, such as HitCount,
TimeCreated, and LastVisit. This
limits you to 17 unique applications
per client-host pair.
I guess this deals more with how many applications you actually run rather than whether you have them all share the same client data store, but it does suggest that there may be some kind of hard limit on the total number of apps you can run at once, although I'd recommend splitting across hosts (or just using a different domain name) if you're planning on more than 16 apps!
As Eric stated above, running multiple apps off of one datasource is fine. What I would warn you is that these databases can fill up fast if you're not careful to block spiders and search engines from using them. Because CF creates client variables on each request for a new session, a search engine will get a new one every time because it never sends its old credentials/cookies so CF thinks it's a new user who needs a new client variable set. Also, be absolutely certain to check "Disable global client variable updates" in CF admin. This will save you a lot of unnecessary overhead.
I would think that multiple applications sharing the same data store would open up the possibility of users from one application having access to the other applications. While it may not be likely, the possibility could exist. (I don't have any facts to back that up, it just seems like a logical conclusion).
The question is, are you comfortable with that possibility, or do you have to absolutely make sure each application is secure?