I've got a Biztalk solution that I'm trying to break apart into the recommended deployment artifacts (Schemas, Maps, and Orchestrations each in a separate DLL), and I'm having a little trouble with one schema in particular.
The orchestration in which I'm using the schema has a single message defined using the schema type. In orchestration view, this message has the error icon (!) beside it. When I hover over the icon, I see "Message Type 'BiztalkPilot.MyMessageType' does not exist or is invalid."
If I change the type's compilation instruction so that it resides in, say, the BiztalkPilotSchema namespace, then the whole thing works. Every other schema in the project is in the BiztalkPilot namespace and they all function correctly.
Obviously I could just switch namespaces and have done with it, but I would like to not have to go there if possible. Does anyone have any idea why this might be happening?
I discovered the root cause here. The orchestration shared the same name as the schema. I'm not sure why that worked when they were in a common project, but once I changed the typename of the orchestration everything worked correctly.
Related
I'm creating some default "drag and drop" templates for our developers, and one section is the required tags. Most of the tags reference a variable: nice and easy. But one wants to reference the resource itself and I cannot figure out a way to it. Does anyone have any suggestions?
The tag itself is called "Context" and it's value should be the "type" of the resource it is in, e.g. "Microsoft.Web/serverfarms". This is desired to aid with billing. Obviously I could either create a different template per resource type (not ideal considering the number of different resources) or rely on the devs to update the field manually (not ideal either as relying on them to add the tags manually hasn't worked so far in a lot of cases), but I am trying to automate it.
Extrapolating from the [variables('< variablename >')] function I did try [resources('type')] but Azure complained that "resources is not a valid selection". I thought it might have complained that it couldn't tell which resource to look at, but it didn't get that far. Internet searches have not turned up anything useful so far.
I can't find a way to do this cleanly either (I hope someone corrects me though! This is a topic for us too). The reference and resourceId functions look promising, but both are unavailable inside of the resources block, would require some parsing, and also require the api version, which you probably also need to vary by resource and so you're just back to where you started. ARM won't even let you use a variable for the resource type property(probably a good thing), so that option is out too.
As such, you'll either have to live with your team having to replace that chunk of text manually or pursue some alternative.
The simplest thing that comes to mind would be to write a script in a language that understands JSON. That script reads the template, adds the tag to the resource, then saves the template again.
A similar approach would be to do it after the resources are deployed by writing a script that loops through all resources and making sure they have the tag. You can use automation to schedule this on a regular basis if you're concerned about it being missed. If you're deploying the templates using a script, you could add it in that script too.
There's some things you probably do with nested templates, but you probably wouldn't be making anyone's life easier or making the process more reliable.
This could be achievable potentially through some powershell specifically around Resource and Resource Group. Would need to run a Get-AzResource either at the subscription or potentially just the resource group level. Then pull the ResourceType field from the object return and use a Set-AzResource command passing in the ResourceID from above and the new tag mapped to the returnedResourceType field.
Something happened to corrupt an ABBYY FlexiCapture project of mine. In the Document Definition Editor, when I expand a couple of my repeating groups, I get:
Internal Program error:
.\DocumentTemplate\TemplateNode.cpp, 626.
Then I can click OK and some of the children elements will load and some will not. This means I cannot update rules in the ones that don't show up.
Is there a known way to fix this? Right now I'm rebuilding the whole document definition.
I'm using the distributed version of the software.
InternalProgramError is usually some kind of unhanded error, thus reference to the CPP file code line. I have no information regarding this specific error, unfortunately, but the fact that it worked before and started to produce the error some time after use indicates that the setup was correct but got corrupted at some point. Otherwise, if you made a change to the template, and started to see that error, undoing that change is the way to go. Usually it is pretty rare to cause these errors in the template modification in the first place, unless you are doing something noncustomary with the UI, or in scripts.
Here is my problem:
I have two C++ modules, A and B, which are built as dynamically-linked libraries. A offers basic math functions, and custom exception types. B is a higher level module that uses A.
B::someFunction() calls a function from A, and tries to catch custom exception A:MyExceptionFromA in order to convert it into a custom type B:MyExceptionFromB (since users of module B do not need to know about the implementation details of A).
Everything works fine as long as I remain in the C++ domain. However, if I expose B::someFunction() in python via boost python, the exception is not caught anymore in the C++ module.
I can catch std::runtime_error, from which A:MyExceptionFromA derives, and call typeid(e).name() to get the retrieve the correct mangled name, so I know the correct exception is thrown. Therefore I suspect that the problem comes from resolving this mangled symbol into the correct exception type.
I have found this link, which explains that "python uses [the insular] model to open extension modules, so that extension module writers don't need to know what symbols other extension modules might be using.". I'm suspecting this is part of the problem/solution, but I do not know enough about symbol resolution to figure out how to solve my problem.
Any ideas?
I found a work-around to my problem. Based on this and link text, I figured out that adding
import sys, dl
sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)
before my includes solves the problem, by forcing python to open libraries in immediate, global mode. But I'm still hoping for an alternative solution, if there's one. As mentioned in the first link, I'm suspicious that this could have unforeseen effects (I already know that name clashing could be a problem, and I suspect performance can be affected as well, but are there other side effects?)
I have a Access ADP Project that has been a continus project for the last 6 years, so it has hundreds of forms and thosands line of VBA code. After a recent update it not wont compile to create the ADE file. It tells me one of the text boxes does not exist but it does. I deleted the for and re imported it from a working backup and still the same error. I have tryed Importing the whole project into a new ADP file and still wont compile, tryed compact and repair and also /decompile
Does anyone no of any tricks or software package to help fix this problem?
I don't work with ADPs, but in MDBs, there are differences between these two syntaxes for referring to controls on a form:
Me.MyControl
Me!MyControl
The first causes Access to create a hidden property that returns the control. The result of this is compile-time checking of references to controls.
The second uses the default collection of the current form and does not provide compile-time checking.
I assume that VBA works the same in ADPs as in MDBs, so why not try converting the offending control references to bang instead of dot? This would eliminate the compile-time checking and might allow the project to compile without having to reconstruct it laboriously.
If that works, I think I would then try deleting the control (to removed the hidden property definition) and add the control back with a new name and then compact (I don't know if ADPs can be decompiled, but if they can, it should be decompiled as well). Theoretically, this should remove the problematic hidden property definition permanently and if that's the cause of the problem, you should be able to revert to the dot operator and get compile-time checking back.
For what it's worth, I've seen too many corruption problems with the dot operator and always use the bang in all my projects. I'm OK with not having compile-time checking of control references.
And, oh, BTW, with the bang you lose automatic Intellisense (which in some cases is a blessing as Intellisense can get in your way in some contexts), but you can invoke a different Intellisense list with CTRL-SPACE. This list is not limited to the control type, but once you start typing, you get the usual autocomplete that jumps you to the appropriate location in the list.
Sometimes it helps to start a new, empty project and then import all forms/reports/modules from the old one.
If birger's approach doesn't do the trick, consider saving each module using the SaveAsText method. Then, as birger suggested, import, but ONLY the forms, and tables. Then, recreate the modules, using the LoadFromText method.
Sometimes, I found out that I need to manual click Debug -> Compile before making ADE files.
This following steps may help for unable-compile ADP file:
Debug -> Compile
Compact/Repair
then make ADE
During coding I frequently encounter this situation:
I have several objects (ConcreteType1, ConcreteType2, ...) with the same base type AbstractType, which has abstract methods save and load . Each object can (and has to) save some specific kind of data, by overriding the save method.
I have a list of AbstractType objects which contains various ConcreteTypeX objects.
I walk the list and the save method for each object.
At this point I think it's a good OO design. (Or am I wrong?) The problems start when I want to reload the data:
Each object can load its own data, but I have to know the concrete type in advance, so I can instantiate the right ConcreteTypeX and call the load method. So the loading method has to know a great deal about the concrete types. I usually "solved" this problem by writing some kind of marker before calling save, which is used by the loader to determine the right ConcreteTypeX.
I always had/have a bad feeling about this. It feels like some kind of anti-pattern...
Are there better ways?
EDIT:
I'm sorry for the confusion, I re-wrote some of the text.
I'm aware of serialization and perhaps there is some next-to-perfect solution in Java/.NET/yourFavoriteLanguage, but I'm searching for a general solution, which might be better and more "OOP-ish" compared to my concept.
Is this either .NET or Java? If so, why aren't you using serialisation?
If you can't simply use serialization, then I would still definitely pull the object loading logic out of the base class. Your instinct is correct, leading you to correctly identify a code smell. The base class shouldn't need to change when you change or add derived classes.
The problem is, something has to load the data and instantiate those objects. This sounds like a job for the Abstract Factory pattern.
There are better ways, but let's take a step back and look at it conceptually. What are all objects doing? Loading and Saving. When you get the object from memory, you really don't to have to care whether it gets its information from a file, a database, or the windows registry. You just want the object loaded. That's important to remember because later on, your maintanence programmer will look at the LoadFromFile() method and wonder, "Why is it called that since it really doesn't load anything from a file?"
Secondly, you're running into the issue that we all run into, and it's based in dividing work. You want a level that handles getting data from a physical source; you want a level that manipulates this data, and you want a level that displays this data. This is the crux of N-Tier Development. I've linked to an article that discusses your problem in great detail, and details how to create a Data Access Layer to resolve your issue. There are also numerous code projects here and here.
If it's Java you seek, simply substitute 'java' for .NET and search for 'Java N-Tier development'. However, besides syntactical differences, the design structure is the same.