What is the ModuleRefCollection, and child ModuleRef, Services and TrackedSchema for in a BizTalk binding file?
ModuleRefCollection is the container for the Schemas (TrackedSchemas) and Orchestrations (Services) associated with the Application. A Module being an Assembly for Orchestrations and the special Application ModuleRef for TrackedSchemas.
Note, TrackedSchemas is a slight misnomer. It contains the configuration for all Deployed Schemas, not just tracked Schemas.
Each element contains all the binding information, what you configure in BizTalk Administrator, for it's respective artifact.
So, a Schema element will list all the Properties you have checked on it's Tracking Tab.
A Service element will have all of the Port and Host Bindings for that Orchestration.
It's pretty easy to interpret yourself. Take any Application you have that has one or more Orchestrations and export the Bindings. You'll see everything you've configured in BT Admin reflected there.
Related
I am trying to add a resource using the BTSTASK command line and it works fine.
BTSTASK.EXE AddResource -Type:BizTalkAssembly /Source:dllpath /ApplicationName:myapp /Options:GacOnAdd,GacOnImport,GacOnInstall /Overwrite
But when the Biztalk assembly such as pipeline has the been used in some other application it won't work unless the port which uses this pipeline is being removed. If i remove the port from the application which uses this pipeline and then using BTSTASK i can add the resource. How this can be easily handled without removing the port of other dependent application.
You can't. The Artifact, Pipeline in your case, is in use and essentially 'locked'.
"been used in some other application" - You should never share artifacts between Applications. Doing so just created this otherwise unnecessary problem. Create a Pipeline in the local Application/Solution.
Using a tool such as BizTalk Deployment Framework, you can just redepoy the entire app taking typically just a few minutes. Almost the same as deploying single Assembly.
I am deploying a Spring Boot application to AWS Elastic Beanstalk using AWSCLI. I want to put an external application.properties file containing customer specification configurations (database credentials, etc.) in the same directory of the application. The application should pick up this properties file. How can I accomplish that? Are there any alternatives?
Spring Cloud Config
This project allows you to use an external, centralized configuration repository for one or more applications. You don't need to rebuild your application if a property changes. You can simply change the property in your configuration repository and even push the changes to all of your applications.
See this Getting Started Guide.
This above approach is what I would recommend for the scenario you described. I would not bother with having a separate directory on the application server for your configuration files. Spring Cloud Config is a great approach as it solves the problem you described and a few more.
You can alternatively specify them in an application-prod property like
server.port=5000
spring.datasource.url=jdbc:mysql://${RDS_HOSTNAME}:${RDS_PORT}/${RDS_DB_NAME}
spring.datasource.username=${RDS_USERNAME}
spring.datasource.password=${RDS_PASSWORD}
spring.jpa.hibernate.ddl-auto=create
and specify an environment variable called SPRING_PROFILES_ACTIVE with the value prod making the beanstalk smart enough to pick values from out there.
I am working on a Biztalk application that has been migrated from 2006 to 2010. What hasn't been recreated are the send and receive ports. Recreating the ports is proving to be tedious. Is there a way to migrate them?
Right-click the application and choose Export -> Bindings.
This will create an XML file with all of the configuration (minus passwords!) on your disk.
Move it to the new server and then right click your application again and choose Import -> Bindings.
This XML file also includes orchestration bindings, schema tracking and so on.
If you just want send/receive ports, delete everything from the XML file that you do not need.
Important: be sure to have the correct adapters/hosts configured before importing the bindings, or you WILL get errors!
Could not find endpoint element with name 'wsHttp' and contract 'Tridion.ContentManager.CoreService.Client.ISessionAwareCoreService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element
while accessing:
ISessionAwareCoreService client = new ChannelFactory("wsHttp").CreateChannel();
When you write software using the Tridion core service, you need to do one of two things:
Create a configuration file for your application that contains the correct WCF configuration
Set up the WCF settings in your software by writing code.
If you are creating a config file, then you can start by copying the default one provided by Tridion. On my system this is at C:\Program Files (x86)\Tridion\bin\client\Tridion.ContentManager.CoreService.Client.dll.config
If your core service client is running on the Tridion server itself, that will probably be sufficient. If you are "off the box" then you'll need to edit it appropriately.
If you want to set things up from code, a good place to start is this recipe in the Tridion Cookbook. (There's also a recipe for the non-code approach.)
i'm a newbie in biztalk.
i have data service access dll which are linked to the wcf.
i've just added a new column so i've updated my wcf.
so the next thing would be to update the dll which are already in the GAC.
just wondering if there's any msdn documentation about this?
or what's the best practice here?
and what exactly goes on when you restart host instance vs restarting the application?
thanks
Stopping/starting a BizTalk application simply stops and restarts the associated Receive and Send ports, and prevents the Orchestrations from acting on any pending subscription items. If you go one step further and un-enlist the Orchestration/Send Port, this removes the relevant subscription from the BizTalk Message Box database.
By compiling and deploying a new definition of your WCF datatype, you have changed the assembly within the GAC (all schemas are compiled and represented as .Net datatypes under the hood). To have this change reflected inside the running Host Instance, you would effectively need to alter the existing DLL that is in the .Net AppDomain. The .Net runtime does not support the removal of assembly types from an AppDomain, so you need to stop, and restart the Host Instance to effect this.
Short answer: Restart your Host Instance for any changes in data definition.