A single Biztalk Server can have multiple Host processes. Is it possible to create an application config file for each host process? For example I would like to use Unity or log4net or whatever which needs such a configuration file.
Edit: Thanks at David Hall. To elaborate a bit more:
We have 12 Biztalk Servers in a group each running between 5 and 10 host processes. Some things the host processes run are unique to each process, but they also share a lot of code on the library level. The trigger for my question was the need to configure for example trace levels for the one system part (equivalent to host process) that currently gives trouble.
As an alternative it would help if I could figure out in which host process the current code is running, but I'll post that to a different question.
If I interpret your question correctly, you want to be able to have a separate version of the BTSNTSvs.exe.config file for each host instance?
So as well as the BizTalkServerApplication host instance, you have YourHostInstance host instances that you want to have a separate config for?
I don't 100% know that you cannot do this, but I am almost sure that it is not possible.
The reasons I'm fairly sure this isn't possible are:
The BTSNTSvc.exe.config file attaches to the main executable BTSNTSvc.exe
Config changes placed in BTSNTSvc.exe.config apply to all host instance regardless of their names.
I've just flipped through the BizTalk books I have to hand as well as some of the good web resources and can't find any mention of someone doing what you want.
So as far as I know, you will need to put the config settings for things like log4net into the BTSNTSvc.exe.config file, and have them the same for each host instance.
One way to get close to what you want would be to load application specific settings from the rules engine.
Related
I've seen some post, including How to manage multiple backend stacks for development?, but nothing related to use lxc for a stable, safe and separate development environment, matching the production environment and regardless the desktop and/or linux distribution.
There was a feature previous to symfony cli release that allowed to specify a socket via ip:port, and this allowed to use different names in /etc/hosts using the 127.0.0.0/8 loopback network, so I could always use "bin/console server:start -p:myproject:8000", and I knew that using http://myproject:8000 (specified in /etc/hosts) I could access my project and keep the sessions, etc.
The symfony cli, as far as I've tried, doesn't allow this. Reading the docs, there's a built-in proxy in symfony cli, but though I've set a couple of projects to use this in the container, clicking on the list doesn't open the project (with .wip suffix), and issues an error about proxy redirections. If I browse to the port and ip of the container ip, it works perfectly, but the port is something that can change with every reboot of the container.
If there's nothing that can be set on the proxy side to solve this scenario, I'd ask to take back the socket feature that existed previously, so I can manage this situation as I used to do before, and solve this.
Thanks in advance.
I think I've finally found a good solution. I've created an issue to improve the situation that seemed not to work, so I'll try to explain for whoever might be interested.
I've setup the proxy server built-in with the symfony cli, but instead of allowing it to run with the defaults, I've had to specify --host=proxyhost (resolvable from the host) and setting proxy exceptions for .com, .org, .net, .tv, etc, together with setting a name to attach for every project (issuing symfony proxy:domain:attach myproject from inside the project dir), I can go to http://myproject.wip just like http://proxyhost:portX, no matter which port is portX.
The Issue
I am currently in the process of integrating a pre-rendering service for SEO optimization, however we use an Azure App Service Plan to scale up or down when necessary.
One of the steps for setting up the proper configuration requires placing an applicationHost.xdt file in the /site/ directory, which is one level above the /site/wwwroot directory where the application itself gets deployed to.
What steps should I take in order to have the applicationHost.xdt file persist to new instances spawned by the scaling process?
Steps I have taken to solve the issue
So far I have been Googling a lot, but haven't succeeded in finding a lot of documentation on using an applicationHost.xdt file in combination with an Azure App Service Plan.
I am able to upload the file to an instance manually, however I have assumed that when we then scale up to more instances the manually uploaded file will not be present on the new instance(s).
Etcetera
We are using Prerender.io as pre-rendering service.
Should there be an easier to set-up & similarly priced service available, we would be open to suggestions as we are in an exploratory phase regarding pre-rendering.
Suppose this won't be a problem, cause all files under azure app are shared between all your instances. You could check it in this Kudu wiki:Persisted files. And in my test all instances will keep the file.
About upload the applicationHost.xdt, you don't have to do it manually, there is a IIS Manager Site Extension to lets you very easily create XDT files. And it will provide some sample XDT's for you.
I am starting to play around with MVC 6 and I am wondering, with the new config.json structure... are my connection strings safe in the config.json file?
Also, I was watching a tutorial video and I saw the person only put their connection strings in their config.dev.json file, not just the config.json. This will mean the application will not have the connection strings while on the production side, correct? He must have meant to put them in both.
Thanks a lot for the help!
I think the Working with Multiple Environments document sums it up pretty well.
Basically, you can farm secret settings such as connection strings out into different files. These files would then be ignored by your source control system and every developer will have to manually create the file on their system (it might help to add some documentation on how to setup a project from a fresh clone of SCC).
For production, the compile will include the production settings. Typically, these are provided by a build server where they are locked away from developers. I'm not sure if that is totally automatic with MVC core or you have to add some kind of build step to do it, but that is how it is normally done.
If you are worried about storing connection strings in the production environment securely, you can extend the framework with your own configuration provider.
I have a nativePath of a file somewhere hosted in server and the value of this nativePath as flex shows me as
Z:\myFolder\myFile.ext
which, I know is also equivalent to
http://particularDomain.myCompany.com/myFolder/myFile.ext
(Note - Z: maps to http://particularDomain.myCompany.com/ which is true in my system and my colleague can have it mapped the same sever to A: in his system)
Now my question is - Can this mapping be realized through Air application in any way? i.e if the native file lies in http://particularDomain.myCompany.com/myFolder/myFile.ext, it says that it lies in that particular server irrespective of whatever it is mapped to?
No, this mapping cannot be realized through any functionality provided in AIR.
How would your AIR app know that there is a web server whose root directory is 'Z:\'? It can't unless you tell it to.
Now, it may be possible to create this functionality on your own as long as you give it a few specific parameters.
If you're app knows that particluarDomain.myCompany.com points to Z:\ it should be easy to write some code to map the two. You could even encapsulate out the domain name and the root in order to easily change them in the future.
You may, also, in theory parse the config file of an Apache Web Server in order to determine the server root and directory location. Assuming that your local machine has access to both. If you're mapping network locations to a local drive; this could potentially complicate things, though.
I have a long process in my cloudbees (roo + spring mvc) app that results in a timeout. According to this previous question a solution would be to change the configuration of nginx (in particular the send_timeout directive ).
My problem is that I´m not sure how can I change this given the fact that I´m not self-hosting the application but using CloudBees for that.
Is this something that I can somehow indicate in the cloudbees-web.xml configuration file? (I haven´t been able to find a complete list of configuration parameters I can include in this file eihter)
Yes you can do this.
You need to change your applications setting to have
proxyBuffering=false
when you deploy. This will allow long running connections. You only need to do this once when you deploy.
eg
bees app:deploy (etc) proxyBuffering=false
you can also use app:update to change an existing apps config (only need to do this once, it will remember it) using the BeesSDK - look for the section on app:deploy and app:update