How to change application server database in k2 blackperl application? - k2

I have K2 blackpearl application which have 2 databases: 1 is k2 database i.e. product database and another is the application database for keeping application data. I am not aware how the application database was configured, but I want to change the application database location to some different serer.
I have already checked smartobject tester and hostserver configuration.
Any idea where i can make connection string changes for this?

If your "Application Data" contains LOB data and is used in your custom solution, you need to perform the following to change it to different server:
Backup that database
Restore it to different server
Edit configuration of Service Instance (SQL Service Instance) corresponding for that database according to that different server
configuration. Usually, it is required to change "Server Name", "Use
Native SQL Execution" and "On Different Server" properties on that
service instance. You can perform these changes using K2 Management site or
SmartObject Service Tester Tool

If your K2 application uses SQL Server as a data source then it most likely uses SQL Server Service broker for this type of integration. If you are new to K2 you have the following logical hierarchy:
Service Type
Service Broker
Service Instance
SmartObjects
Service Broker it is something that allows you to connect to external system (SQL Server in your case) and Service Instance represents instance of this system accessible to K2 (SQL Server database) based on which you can create SmartObjects - representations of objects within external system with which K2 can interact (SQL tables, stored procedures etc. in your case).
I hope from description above it is clear that your app DB connection string lives at Service Instance level. To adjust it you have to do the following:
1) Run SmartObjects Services Tester (default location: "C:\Program Files (x86)\K2 blackpearl\Bin\SmartObject Service Tester.exe")
2) Expand SQL Server Service category and select service instance corresponding to your app database. It should be clear from name (if naming conventions were followed when it was created), but if not just edit its properties - there you will see Database and Server properties corresponding to SQL database name and SQL Server name respectively.
3) Once you located right service instance just edit its properties adjusting server and database name. Here how it looks like:
If necessary refer to #Dragan Panjkov answer or documentation I mentioned above for information about additional settings you may need to adjust.

To do this you need to run the K2 setup tool - you can access it from the start menu. You just need to run through the wizard (which will be pre-populated with your existing settings), and update the K2 database settings when you get to it.

Related

Specify postgresql database name in cloud foundry manifest.yml

Is there a way to specify a postgresql database name to connect to in the cloud foundry manifest.yml file? I've been raking through the documentation and haven't yet found this specific information.
I'm imagining something like this:
applications:
- name: my-app
routes:
- route: my-app.mybluemix.net
services:
- postgres
dbname: database2
With that approach, a postgresql connection can be made by just the connection string provided by VCAP_SERVICES parsing modules (cfenv in the case of node).
If this is not possible, I will just set a dbname environment variable and build my own connection string.
There is nothing like that in a Cloud Foundry application manifest.yml.
The manifest.yml only takes a list of service instance names and the services with those names will be bound to your app. It does not allow you set other metadata.
https://docs.cloudfoundry.org/devguide/deploy-apps/manifest-attributes.html#services-block
I don't know if these will help, but when you cf bind-service directly there are two additional provisions you can make use of (these are not supported by manifest.yml as of me writing this):
Arbitrary bind parameters. These probably won't help unless your service broker supports them, but it's a way to pass additional info to the service broker. If your broker supported it, you could in theory say give me a database named XYZ by passing it some config this way.
Named service bindings. This provides what amounts to a second name. The intent is that you can create the service with a name of X, but your application can look for a service binding with name Y. You can use this to swap in differently named services, but still expose the same binding name to the application so it will always find the service.
If you are trying to pass in some other service instance related metadata to your application, you'd need to do it some other way. Like if you want to tell it the database name or the connection pool size, etc.. Using environment variables like you mentioned is one option. You could use a config file or cli arguments passed to your application. What you pick is probably a matter of preference/support in the library/framework you're using.
For what it's worth, most service brokers I've seen pass in and tell you a specific database name to use. If the broker said connect to db XYZ and you made your connection to myCoolDb, the connection would fail. Just wanted to mention this. Your mileage may vary.

Azure database works on localhost, but not when used with azure service app

So I've been trying to publish my first project to azure. I've got everything set-up, a service app and a sql database.
My initial page loads properly(It's the standard view for a .net core web application).
The first thing I need to do is register a new user. Whenever I try through my azure app (myapp.azurewebsites.net) it fails and the logs says it's db related.
However I try the same thing by running the application on my machine in production environment, again connected to the azure sql server and everything works perfectly. I can register users, I can create posts, I can edit them. The allow access to azure services option is turned on. This error is from the eventlogs. I have not included the stacktrace.
Category: Microsoft.EntityFrameworkCore.Query EventId: 10100 RequestId: 800001be-0000-ba00-b63f-
84710c7967bb RequestPath: /Identity/Account/Register SpanId: |1e5a93ae-43f424904f38ea9f. TraceId:
1e5a93ae-43f424904f38ea9f ParentId: ActionId: c3430236-e61c-4785-a3c3-4f60ba115b6e ActionName:
/Account/Register An exception occurred while iterating over the results of a query for context type
'MyApp.Data.ApplicationDbContext'. Microsoft.Data.SqlClient.SqlException (0x80131904): Server
name cannot be determined. It must appear as the first segment of the server's dns name
(servername.database.windows.net). Some libraries do not send the server name, in which case the
server name must be included as part of the user name (username#servername). In addition, if both
formats are used, the server names must match.
Those are the different ways I tried to add the connection string to the appsettings.json file. (Server name, catalog, user and password have been replaced, they are written correctly in the appsettings file)
Server=tcp:servername.database.windows.net,1433;Initial Catalog=db;Persist Security Info=False;
User ID=user#server;Password=mypassword;
MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Server=tcp:servername.database.windows.net,1433;Initial Catalog=db;Persist Security Info=False;
User ID=user;Password=mypassword;
MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Data Source=tcp:server.database.windows.net,1433;
Initial Catalog=db;User Id=#server.database.windows.net;Password=password;
Alright so after a day and a half, I finally managed to fix it. The solution is rather simple and it is most likely my newbie mistake, that caused so much trouble.
I was following a tutorial for setting up the application and database connection after that. In the tutorial, the connection string that was being used, was the default one, found in the "myApp -> Configuration -> Connection strings", the format was:
Data Source=tcp:server.database.windows.net,1433;
Initial Catalog=db;User Id=#server.database.windows.net;Password=password;
This one was working in the guide, but not for me. So what I did, was go to my "sqldb -> connection strings" and copied the one provided there. I then went back to the app configuration and added it as a new configuration string using SqlServer as the Type.
This string was in the format:
Server=tcp:servername.database.windows.net,1433;Initial Catalog=db;Persist Security Info=False;
User ID=user;Password=mypassword;
MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
After that, the app started working properly.

Play Framework how to set jdbc properties after startup

In my play application the database settings are not known before startup of the application. I have to read them from an environment variable after automatic deployment and start of the application.
The platform the app is deployed on is cloudfoundry. And there is a environment variable called VCAP_SERVICES (that is a json string). Here are all services listed e.g. the database service including the credentials
Is there a prefered way to do so? In means of still being able to use stuff like:
DataSource ds = DB.getDatasource();

Windows ServiceBus 1.1 for Windows Server

I did move the databases from our ServiceBus test enviroment.
I started by leaving the farm with the single node, then I moved the databases.
After rejoining the farm I see that GatewayDBConnectionString is till pointing to the old one.
I can't find any valid PowerShell command to reconfigure the value in question.
Anyone know how to fix this?
Thank you in advance.
To answer this I will need you to understand this a bit more - and hence giving a high-level overview of Service Bus 1.1 Server farm configuration:
Service Bus Server 1.1 is a platform where users can create highly-durable distributed Pub-Sub (messaging Queues/Topics) entities. In simple words - the main job of this is to translate the Compute (your VMs) and Data (your MsgContainer databases) into messaging functionality Durable Queues and Topics. So, in short - the configuration wizard or the Powershell cmdlets used to configure ServiceBus 1.1 Server will try to take the VMs and Databases from you.
The Db SBManagementDB is considered to be the authoritative source of truth for any Farm level configuration -> like Nodes that are part of the Farm (Store.Nodes), Ports opened on each of the nodes, Gateway database connection string (Cluster Config) etc. Also pl. note that - as per the Windows Server product guidelines - any information that has to be securely persisted will be encrypted - so as the Gateway DB connection String.
a) when you did New-SBFarm (with a Gateway DB connection string) - you have essentially communicated to SBMgmtDB - the Gateway DB Server, database name etc.
b) when you do Add-SBHost - again you have communicated to SBMgmtDb that you want to add one Node to this Farm
Gateway db connection string is the one place for Truth for all Gateway Services to find any run-time info -> like Container Databases, entity to container mapping etc.
again, when you do New-SBMessageContainer PSCmdlet --> you communicated to SBGatewayDB that you are adding one db
Now, with this background - lets see how the action you did above will take into effect:
- When you moved all the Databases to a different Server - you changed the Gateway Database connection string - But the Gateway connection string you had communicated to the SBManagementDB (using the New-SBFarm cmdlet) was pointing to the Old Server.
- When you removed the Node from the Farm and again Joined back - you removed one node from the configuration and re-added it - no affect :)
The ANSWER
Use Restore-SBFarm PS Cmdlet to communicate to the SBManagementDB that you changed the GW db
and then Use Restore-SBMessageContainer PS Cmdlet to communicate to Gateway DB that you changed the Container databases.
Now, add the Nodes back to this restored farm.
HTH!
Sree

Configure AppFabric Cache without listing servers in web.config

I am trying to understand how to properly configure AppFabric Caching on a web site. We are planning to use SQL Server as the cache manager and as far as I can understand the SQL will contain a list of the cache hosts in the cluster.
However, when running
DataCacheFactory factory = new DataCacheFactory();
I get
Server collection cannot be empty.
which, I guess, is to be expected since I have not added any servers in the web.config.
However, I do not want to maintain a server list on each web server, I want that to be done centrally on the SQL Server. I assume there is a way to point to the SQL Server, but I cannot find information on how to do this.
(I have also tried with the XML configration option, but it cannot even find that file. I have checked the health of the service in power shell.)
How do I centralize the server cache host list?
We are planning to use SQL Server as the cache manager and as far as I
can understand the SQL will contain a list of the cache hosts in the
cluster.
It's false. SQL Server can perform cluster management but it's only for managing the cache hosts, and ultimately, the cache cluster. It's just for internal management and your clients can use this configuration and they don't need to have acces to Sql Server.
DataCacheFactory factory = new DataCacheFactory();
This code will try to load default datacacheclient in config. In your case, it should be empty that's why you get this error.
You can still use code to configure cache host in this way.
// Declare array for cache host(s).
DataCacheServerEndpoint[] servers = new DataCacheServerEndpoint[1];
servers[0] = new DataCacheServerEndpoint("CacheServer1", 22233);
DataCacheFactoryConfiguration factoryConfig = new DataCacheFactoryConfiguration();
factoryConfig.Servers = servers;
DataCacheFactory mycacheFactory = new DataCacheFactory(factoryConfig);
DataCache myDefaultCache = mycacheFactory.GetCache("NamedCache1");
You don't need to specify all host names here, because AppFabric Caching will route request to the correct cache host, event if it is not in your list.