Should/can a BizTalk BRE ruleset have multiple versions?
I've been given an export of some BRE rules and noticed that some of the rulesets have got multiple <version> elements, e.g.
<brl xmlns="http://schemas.microsoft.com/businessruleslanguage/2002">
<ruleset name="ExampleRule">
<version major="1" minor="3" date="2013-04-17T19:02:05.748159+01:00" />
<version major="1" minor="0" date="2013-04-17T19:05:58.2361695+01:00" />
<...
<ruleset name="ExampleRule">
<version major="1" minor="2" date="2013-03-29T08:23:43.6502257+00:00" />
<...
Is this valid?
Multiple deployed versions of a Policy are supported by the BRE itself and in the API you can specify a version number by overload, otherwise, the highest deployed version is used.
However, specifying a specific Policy version is not supported by the Call Rules Shape. So, the Call Rules Shape will always use the highest deployed version of a Policy.
Whether or not you maintain multiple versions depends on the app in question. I have seen cases where this is required for the business process or maybe regulatory needs. A way to accomodate this in BizTalk is to use a "Master Policy" in the Orchestration which internally figures out and executes the appropriate Sub-Policy version.
As for the version elements, this appears to be a valid construct but I can't reproduce it. The Wizard will only export one version or a Policy at a time, so, this was either exported in code using the API or was cut-and-paste together. I have used the API and not noticed this.
Either way, the import function will apply the version info from the last version element in the xml, not the highest version, so if you reorder the version elements, you will get inconsistent results.
And one final wrinkle, the multiple version elements are preserved in the same order through import/export.
Related
We have a similar problem to that of the asker of this question -- after upgrading from log4j-2.17.1 to 2.17.2, the application, though otherwise working, is not logging anything.
Having read the release notes, I see the following part:
By default, the only remote protocol allowed for loading configuration files is HTTPS.
Users can specify a system property to allow others or prevent remote loading entirely.
Indeed, in our case the log4j2.xml is downloaded via regular (non-encrypted) HTTP, and that likely explains our problem (as well as that of the other guy). However, try as I might, I cannot find, how to (re)enable the ability to use HTTP -- which system property is it, that now controls the capability?
Thanks!
The system property you are looking for is called log4j2.Configuration.allowedProtocols (cf. documentation) and should contained a comma separated list of URL schemes (e.g. "http,https").
You can set it using any available property source (e.g. a log4j.component.properties file or a Java system property).
We are using a large third party API with many optional features. There are 27 endpoints and we need only a few of these from Maven. We are using server side generation.
If you are interested the API is here: https://github.com/mjeffrey/psd2
Ideally we would only generate and expose the ones we support.
Is it possible to just generate a list of API endpoints or exclude ones we don't want to support?
I see there is the possibility to generate only certain models but that is not what we need. the -D apis parameter seems tor be treated as a boolean in the source code.
https://github.com/OpenAPITools/openapi-generator#3---usage
https://github.com/OpenAPITools/openapi-generator/blob/master/docs/customization.md#selective-generation
I'm also considering a pre-processor so we don't need to manually edit the yaml file (which is updated regularly). Any suggestions for preprocessing the yaml file?
The way to do this is to use the environment variable apis and provide a comma separated list of the root path-segment. Unfortunately in our case the root is /v1 so we get only one "api" generated and we can't select individual paths.
Stripping off the /v1 from all the paths we can then use:
Command line
java -Dapis="consents,{payment-service},accounts"
Maven
<configuration>
<environmentVariables>
<apis>consents,{payment-service},accounts</apis>
</environmentVariables>
</configuration>
So as you may or may not know, BlazeDS (open source version of LiveCycle Data Services) is a nice way to get your server-side Java and client-side Flex application to play together. Unfortunately, it does have several pitfalls that need to be corrected. I'll try to explain one of them here.
All of BlazeDS's configuration is written via XML files in the flex/ folder of your webapp. The default names are separated for clarity, such as services-config.xml, remoting-config.xml, messaging-config.xml, etc. In these configuration files (particularly services-config.xml), Channels are defined; these setup URIs and objects used to capture and send information between the server and the client. In these config files, it is quite common to use a syntax like so:
<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
<properties>
<add-no-cache-headers>false</add-no-cache-headers>
</properties>
</channel-definition>
Unfortunately, what they don't tell you is that some of these key-in replacements (ie: {context.root}) are not replaced dynamically upon execution but upon compilation of the WAR file you intend to distribute. Obviously not a good idea when switching domains.
So, instead I seek to dynamically define these channels. According to the documentation, that's all good and fine, but it only works if the channel already exists when the webapp is launched. I feel like that sort of defeats the point.
So my question is, how do you truly create channels dynamically so that both the client and the server recognize their existence?
Read this blog post; I believe it is what you're after.
I believe these xml config files have no direct relation to the server at all. They are used to tell the SWF how to find the server.
During Compile time of your Flex App; the services-config information is, in essence, hard coded into the SWF.
When using HP-UX I can use the chatr utility to report on various internal attributes of a shared library. It will also allow me to modify the internal attributes of shared libraries that I have built.
The chatr utility can report, and in some cases modify, such things as:
the run-time binding behaviour,
the embedded library path list created at build time,
whether the library is subject to run-time path lookup,
internal names,
etc., etc.
Is such a utility available for Solaris?
Edit: Freaky! Thanks to mark4o's answer below I revisited the elfdump output for a typical system .so (libm.so.2 on Sol 10). However, and here's the freaky part, I mistyped the command to enter:
elfdump libm.so.2 | moe
In an amazing stroke of serendipity, this gave me back the usage message for a utility called moe whose man page description section says:
The moe utility manifests the optimal expansion of a path-name containing reserved runtime linker tokens. These tokens can be used to define dependencies, filtees and runpaths within dynamic objects. The expansion of these tokens at runtime, provides a flexible mechanism for selecting objects and search paths that perform best on this machine.
This will help me resolve why a libm.so.2 shlib is not compatible on both of two different machines leaving my incomplete executable unable to start on one server.
For displaying the information, see the Solaris elfdump and pvs utilities. For debugging binding issues, lari and moe may also be helpful. However, these utilities do not have the ability to modify the library.
Starting with Solaris 11 (and some of the OpenSolaris & Solaris Express releases leading up to it, but not Solaris 10 or older), there is now an elfedit tool for modifying runtime paths and similar attributes.
I recently worked on an app in a very interesting environment. There was 6 or 7 parallel levels for this application and only the 1st 2 levels were able to be touched by developers. As part of the company policy all builds were done as Tivoli packages, and very complex to setup.
The final kicker was that no code changes are allowed past the 1st level or "Dev" servers so web.config contained multiple encrypted sections of environment variables. The application is built to sense what environment its on by path and variables set in IIS.
This is a beast to maintain so what is a simple or better architecture for this type of problem?
Hmm, (disclaimer: I'll talk about something I've written)
Your subject seems slightly different from the post, but I think I have an idea of what you mean. The tool I'm writing, dashy, lets you handle a single codebase, and lets you configure it for various enviroments. It doesn't, however, place security restrictions on these enviroments over the other. But, depending on your source control, and general system, it may be of interest. You should get a reasonable idea of the way it works from the picture on the homepage. Perhaps it's of interest, perhaps not, but it's what we use to manage deployment to different environments. It's a work in progress ("beta") at the moment, but the current version is suitable for testing.
The latest version of ASP.NET now supports web config transformations, allowing you to change specific settings within your project for deployment, testing or staging. Here's a great intro by Tom Hundley.
Have you tried using OpenExeConfiguration of the ConfigurationManager and explicitly load the proper configurations for the appropriate environments instead of just using the default web.config?
For more, check out OpenExeConfiguration on MSDN
You could include all configurations for all environments in the web config and prefix their keys with the machine name of the appropriate environment. Then, using Server.MachineName (or some other way to identify the server that the app is running on) you can access the right configuration.
<appSettings>
<add key="DEVMACHINENAME_baseURL" value="http://dev.foo.com" />
<add key="QAMACHINENAME_baseURL" value="http://qa.foo.com" />
</appSettings>
No one would have to go in and modify anything in the web.config since the application can look up information for itself.