I am new to a WebSphere Commerce Enterprise v6.0 environment that has already been set up. I was wondering what would be the most definitive way for me to determine which servers are used as Production, which are used as Staging and which are used for Testing?
To my knowledge, WCS has so far not included a DB entry or a script that can return the nature of a WCS server. If there is IBM will need to clearly document it.
The best way to find out in [out-of-the-box] WCS installations what is the nature of a WCS server is probably a query like this:
SELECT CASE
WHEN count(1)>0 THEN 'STAGING'
WHEN count(1)=0 THEN 'PRODUCTION'
END AS WCS_TYPE
FROM STAGLOG WHERE STGPROCESSED = 1;
(Note: A simpler check could just rely on the existence of the STAGLOG table, but I've seen many WCS servers that have this table without being a Staging server.)
The other option is to add a proprietary/custom system property or WCS server.
Non-staging will never have staging triggers.
select * from syscat.triggers where trigschema = CURRENT_SCHEMA and trigname like 'STAG%';
It depends on how you set it up [http://www.ibm.com/support/knowledgecenter/SSZLC2_7.0.0/com.ibm.commerce.admin.doc/tasks/tsscreatestagingserver.htm]
To find from DB if the environment is LIVE or STAGING is to query the STAGLOG table.
If we find entries in STAGLOG table, then that is a STAGING environment. This entries are created by TRIGGERS for Staging Database tables.
In LIVE we will not be having entries in STAGLOG table.
Related
I have SOAR that uses boltDB to host it's incidents.
I want to take that boltDB copy over to DEV environment and leverage its data without compromising PROD data.
New to BoltDB; are there tools available for me to review / query bolt DB database. Ultimately looking to see if I can script a solution to scramble certain values within the boltDB?
I am following this guidance: https://www.mssqltips.com/sqlservertutorial/3806/sql-server-master-data-services-importing-data/
The instructions say after we load data into the staging tables, we go into the MDS integration screen and select "START BATCHES".
Is this a manual override to begin the process? or how do I know how to automatically queue up a batch to begin?
Thanks!
Alternative way to run the staging process
After you load the staging table with required data.. call/execute the Staging UDP.
Basically, Staging UDPs are different Stored Procedures for every entity in the MDS database (automatically created by MDS) that follow the naming convention:
stg.udp_<EntityName>_Leaf
You have to provide it values for some parameters. Here is a sample code of how to call these.
USE [MDS_DATABASE_NAME]
GO
EXEC [stg].[udp_entityname_Leaf]
#VersionName = N'VERSION_1',
#LogFlag = 1,
#BatchTag = N'batch1'
#UserName=N’domain\user’
GO
For more details look at:
Staging Stored Procedure (Master Data Services).
Do remember that the #BatchTag value has to match the value that you initially populated in the Staging table.
Automating the Staging process
The simplest way for you to do that would be to schedule a job in SQL Agent which would execute something like the code above to call the staging UDP.
Please note that you would need to get creative about figuring out how the Job will know the correct Batch Tag.
That said, a lot of developers just create a single SSIS Package which does the Loading of data in the Staging table (as step 1) and then Executes the Staging UDP (as the final step).
This SSIS package is then executed through a scheduled SQL Agent job.
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.
Since 2.2.0, OrientDB now has a system database named OSystem. I'm looking for a way to configure the path to this database independently from other databases? Is this possible? Can I do this at runtime with environment variables?
Thanks!
This is currently not supported.
However, I'll try to add support for this in an upcoming release.
Thanks for the suggestion.
-Colin
OrientDB LTD
The Company behind OrientDB
I've done some tests, trying to set different paths in orientdb-server-config.xml properties, but after every server start OrientDB checks for OSystem DB presence, and if there is no one, it will automatically create it in default /databases/ folder:
2016-06-17 15:13:26:738 INFO {db=OSystem} Creating the system database 'OSystem' for current server [OSystemDatabase]
The application I develop is deployed to severeal environments (development, test, staging, production).
While developing I created the entity model from the existing development-database. Everything works fine, but as I wanted to put the application onto the test-environment, I realized the following problem:
The structure of the database is identical in all environments, but the database schema changes from environment to environment. For example there's a Customers table in every database. On my local dev machine it has the schema dbo ([dbo].[Customers]), but in the test environment the schema is test ([test].[Customers]), whilst the schema is stag in the staging environment ([stag].[Customers]) and so forth.
So when I deploy the application in the test environment, it gets no data from the database, because the entity framework expects the data to be found in [dbo].[Customers] but there is no such table, there is just a [test].[Customers].
I know, that I can define a schema other than dbo, but this doesn't help me, because I need a different schema depending on the deployment environment.
Any suggestions?
Somehow I think I'll be ending up, asking my DB admin to change the schema to dbo in every database in each environment...
If you are using code first you have to use fluent API approach from linked question and load current schema from configuration file (you will have to modify configuration per each deployment).
If you are using ObjectContext with EDMX you can use Model adapter. Other way which works with DbContext as well is storing EF metadata in files and executing some code which will change schema in ssdl file at application startup.