I'm trying to add my Service Broker queues to my database project and I'm not entirely clear on what is the best way to do this. There are two views available to me, Solution Explorer and Schema View. It seems like the only way to get a Service Broker Queue, along with all of it's associated messages/services/contracts is by adding the Queue in the Solution Explorer view and then adding everything else in the Schema View.
Is this correct? Is there not a unified view for all this? What are the best practices for including Service Broker in a Database Project?
The Queues are visible under the Schema View, they just aren't grouped with the Service Broker section, but instead are located under Schemas -> [SchemaName]-> Queues.
Why they aren't grouped together is completely beyond me.
Related
I know there are many questions like this and almost all answers are No. And the reason is a single microservice should be independent of another one. And if there is a change in a table, all microservices using that table need to be changed.
But my question is, if my database structure is fixed (hardly there will be any change in the table structure) will it be a good idea of creating multiple microservices pointing to same database.
Okay... here is my project.
We are going to a migrate struts 1.3/EJB 2.0 project to Angular/microservices. This project has 5 different modules and each module is a huge one. And this project is there in production since past 13 years. So there is very little chance of changing the table structures.
The reason I want to make different microservices is, since each modules are huge and complicated, and we still get requirements to add/change the business logics. So in that case, I can deploy only one microservice.
Any suggestions please.
I suggest creating a new service that access that database and all other services communicate with this service instead of directly to the database.
If you don't want to create a new service, at least access the DB using some database
abstraction layer.
For example, in SQL server use views and store procedures instead of directly access the tables.
I am new to sitecore and just trying to understand its architecture/design. Just curious to know how Intranet and Internet server communicates and how does the data flow happens between these two layers in on-prem and on AWS EC2 environment? I have surfed enough in the web and couldn't find the appropriate explanation.
Really appreciate if anyone can help me understand.
When u do a publish from CM, it puts a record in eventqueue table in Web Db.
all CD servers will hit the eventqueue table table for update and proceed.
default is 2 seconds once this hit happens.
In short, they communicate via events in the database(s). Note: This is very simplified but seeing it this way helped me understand how the events work and troubleshoot issues.
For example, when publishing an item, the publisher (running on CM or on a dedicated role) reads its data from the master database and writes it to the web database. When done, it raises an event by writing a row in the EventQueue table in web database. The CD server(s) picks up this event and clears its corresponding caches etc. causing a reload of that data from the web database.
All Sitecore databases have the EventQueue table and events goes to the table in different databases, depending on the type of event. An events is basically just a class name and a set of serialized data. Events can be raised "locally" and "globally" indicating if several instances should pick up the event. Think of a scenario where you have two CD servers sharing one web database, both CD's would have to pick up the event.
To keep track on what events has been processed, a "EQSTAMP" value is stored in the Properties table. It's named [database]_EQSTAMP_[InstanceName]. It's therefore essential that not two Sitecore instances share the same instance name. If not set, Sitecore will make an instance name by combining the hostname and IIS site name. The decimal Value of this timestamp corresponds to the hexadecimal Stamp column in the EventQueue table.
Normally, you should never have to play with these tables yourself, but I find it good to have some insights in how they work and keep an eye on them. They can grow in size and cause some issues. The CleanupEventQueue scheduled task is responsible for removing old processed events from the EventQueue tables. You may want to play with the scheduling of this agent if your EventQueue grows too large between cleanups.
Note: This is the most common way of communication between the servers. Later versions of Sitecore have other techniques as well, such as Rebus.
Event Queues. Why? How? When? article that explains it in detail, it also describes the pitfalls of using this mechanism in real life as well.
Please also be aware that Sitecore.Link project is a good place to get more knowledge regarding Sitecore functionality.
It accumulates Sitecore knowledge all around the web.
Thanks.
I am mapping users to connections as described in the following link https://learn.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/mapping-users-to-connections so I can find which user's to send messages to.
I was wondering if there is any additional work required for this to work smoothly on multi node servers / load balancing. Im not experienced on the infrastructure side but I'm assuming if there are multi servers spun up, there would be multiple static hashmaps storing the mappings of users to connections - i.e., one for each server.
Would this mean users that have made a connection from their browser to node A will not be able to communicate to users who've connected to node B ?
If this is the case, how would we go about making this possible.
In that same link, just below the Introduction section, it discusses 4 different mapping methods:
The User ID Provider (SignalR 2)
In-memory storage, such as a dictionary
SignalR group for each user
Permanent, external storage, such as a database table or Azure table storage
And after that there is a table that show which of these works in different scenarios. One of those scenarios being "More than one server".
Since it is not mentioned, it depends on which mapping method you are following.
From there, you can check out "scaling out" on the same site you noted which has several methods you can follow depending on what suites your needs. This is where sending messages to clients regardless of which server they connect are handled.
I am looking for alternatives for managing my RabbitMQ setup, same as i manage my RDBMS with liquibase/flyway or mongo with mongeez.
After looking around a bit I havent found any resources on it as much (Which gets me thinking on how companies actually do it).
I read thread that talked about each component creating the channels that it needs to its either there or it will be created in runtime when needed.
Other then that i haven't found any mention of a request like mine, am i looking at this the wrong way?
We manage it the following way. It's not a clean straight forward solution, but it works.
Installation, update and base-configuration of RabbitMQ is done via an ansible role.
Creation, update and deletion of virtual hosts, users and access permissions is done via a second ansible role
Management, i.e. create, update and delete of queues and exchanges is done from within the application
With this setup we were able to provide a multi tenant configuration and efficiently manage several installations in several stages.
Can someone please explain the intended purpose of the client and server components under the advanced "arrow" option in the Local Database Cache > Configure Data Synchronization dialog please?
I just want to call SyncAgent.Synchronize(). Why do I need the components, and how to use them? Why put them in a single project location or 2 different locations?
Your help is greatly appreciated!
some people prefer using an n-tier setup and the multi-project, separate client/server component setup allows them to keep the actual connection and synchronization tasks at the back end database on the server side wrapped in a WCF service.
Likewise, in the older Window Mobile based sync is also on a multi-project, n-tier setup.