As I understand from the documentation for Azure resource naming rules, I should be able to create a VMSS using Windows OS with up to 15 characters.
Source: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftcompute
Yet, when I deploy my ARM template for a Service Fabric Cluster, the deployment fails because the name is too long, which is 13 characters.
I am using "apiVersion": "2019-07-01", for the Microsoft.Compute/virtualMachineScaleSets type in the template, which appears to be the most recent version.
I can definitely make the deployment work be shortening the node type name but I'd prefer to take advantage of the additional characters that appears to be possible in the documentation.
Has anyone else been able to use more than nine characters for the node type name? If so, how?
last 6 characters are reserved for node incremental names (starts from 000000 and incremented by 1 for each node). Nothing you can do about it. Use 9 characters max
Related
on Flyway deployment script name starts with a version.
What is the maximum length one can use? I see that on the table column holding the version is 50 character long
There are a number of limits:
Version must be 50 characters or less
Description must be 200 characters or less
Migration filenames must be compatible with any OS limit
Do you have a specific use case for a version string longer than 50 characters? We're in the middle of work for Flyway 7 and this is a chance for us to change the history table if there's a good reason to do so.
If you read the documentation located here, you'll find that the limit is not one from Flyway. Rather, your limit on the length of the version is based on the OS and it's limit on the size of a file name. You must ensure that you're incrementing your numbers in an appropriate order. However, as you can see in the docs, Flyway supports a wide variety of formats, and the length of your string defining the version number is not an issue you need to worry about.
Diagnosing an issue with a BizTalk app where part of it's logic doesn't seem to be triggering.
Currently it's designed to use a Decision Shape to filter on 2 values from a specific message.
One of those values is the word 'staff' in lower case, whereas the map that constructs the message uses a string functoid to populate the value as 'Staff' (sentence case).
I'd test this to see if it's the cause, but we don't currently have a test environment, and there's about 8 apps that this is a dependency on, so I'd need to go through a convoluted process of taking them all offline and deploying the small fix at a gamble.
On that basis, would anyone know; Is BizTalk Decide Shape Expression logic case sensitive?
Yes, the decide shape is case sensitive.
I tested with a rule
Message(FILE.ReceivedFileName) == "D:\\in\\YES.xml"
I dropped through a files YES.xml, yes.xml and YES.XML, and only the YES.xml went through the Rule branch, the other files went through the Else.
This is probably due to C# being case sensitive, see Is there a C# case insensitive equals operator?
I'm new on Java Card applications. At this moment I would like to store a hash table (dictionary) that contains the configuration of a terminal that reads this type of cards. If the hash table has values, those must be retrieved to the terminal (I think using APDU's right?) but also if there are no values, the terminal must create a "default" initial configuration.
Is it possible to do this? If it is, how? Maybe there is an applet ready for that (like Musclecard for key generation and signing) but I haven't found any.
Any advice? Thanks!
Java Card is pretty limited regarding support for data structures. It has a few basic types such as byte and short and optionally int, which is not used anywhere in the classic API. For those types you can generate two types of transient (RAM) arrays using JCSystem.makeTransientByteArray() and friends. Furthermore, the default byte[], short[] and Object[] created using new are stored in EEPROM.
The Object class in Java Card has been stripped down as well. This means that there is no such thing as hashCode(). If it was present then you would run into problems as the Java SE version of hashCode() returns an integer, which is probably not present. All defined data containers are either smart card or security related (e.g. the APDU and Key classes).
So basically, if you want to create a HashMap - the common type of dictionary on Java SE - then you will have to create it yourself. It is in that case a good idea to define a Hashable interface that classes can implement to act as a key. The structures should be generated in the right type of memory. For the kind of application you specify you probably need persistent memory, which is kind of the default for object instances created using the new key word.
Personally, I would make very sure you need a hashCode() method for your solution. It is probably easier to create an Object array and simply iterate over the elements.
Since there is no hash table in the smart card, you can store the terminal configurations in byte arrays. The smart card only stores the configuration (and optionally protect the data), and the instruction to get stored configuration or to update it shall be sent by terminal via APDU command.
Suggestion 1
Put your configuration in a Linear Fixed EF, if the card supports file system. No applet needs to be created/installed. It's the terminal job to read all records of the file to determine whether a configuration exist or not, and to write configuration into the file using standard APDU (UPDATE RECORD, READ RECORD).
NOTE:
set record length as number of terminal configuration bytes
number of records denotes the number of configurations that can be stored
you can put initial condition to indicate that the record is unused, e.g. 00...00
Suggestion 2
Create your own javacard applet. The applet must handle at least three proprietary APDUs:
Get list of terminal configurations
Update a record of terminal configuration
Delete a record of terminal configuration
NOTE:
You need to handle how to store and return the bytes between APDU format and your storage
I am currently implementing an EDI solution in BizTalk Server 2010.
This is the scenario:
BizTalk is responsible for the correct message routing between a X.400 mailbox and the customer's ERP software. It is also used to put information about the exchanged message into a SharePoint site using the SharePoint webservices.
I am using Role Links and the BizTalk party management to apply the correct settings (send ports, password in UNB6 segment, etc.).
Now I have the following question:
When I try to fetch an outgoing INVOIC message from the customer's ERP system, extract the relevant information in an orchestration and write it into the SharePoint site, the receive port using the EDI receive pipeline gets suspended with the following error message:
An output message of the component "EDI disassembler" in receive pipeline
"**********.Pipelines.FileNamePromotionEDIReceivePipeline, **********.Pipelines,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=****************" is suspended
due to the following error:
Error: 1 (Miscellaneous error)
33: Invalid occurence outside message, package or group.
The sequence number of the suspended message is 1.
This happens because the message uses a CR and LF as suffix after each segment delimiter. Now I could add the ASCII-hex-codes for CR and LF to the "EfactDelimiters" setting of the pipeline, but the problem is that there are other messages without the CR and LF, which then could not be received using the same pipeline. By the way, when I fetch one of those messages without CR and LF using the pipeline also without CR and LF set as delimiters, the receive port also gets suspended, this time with an error message resulting from the usage of dots instead of commas as decimal separator (although I have enabled the option "UseDotAsDecimalSeparator" in the pipeline). Again, only changing the EfactDelimiters helps.
I thought that the "Character set and separators" page in the party agreement was supposed to make exactly that possible: To set the delimiters individually for each business party. But the changes I make in these settings seem to have no effect whatsoever. I set the "UNA6 Suffix" to "CR LF" and the "Decimal Notation (UNA3)" to ".(Decimal)", restart the host instance... same problem.
Can anyone help?
I never used biztalk, but I know my EDIFACT, and as far as I know, those messages containing CR/LF are syntactically wrong. The UNA6 Suffix seems to be an addition by Microsoft, as I can find no trace of it in the official documents on EDIFACT at UNECE.
Normally, the chars you want to use as special chars in an EDIFACT message are set by the special (optinal) UNA segment, which always comes first. When you write, you set the separators / delimiters, I don't really know, what you mean by that, as it could refer either to setting the options for the created message (what delimiters are used in the message), setting the delimiters used for parsing by the receiving program, or it could refer to the chars that are printed in the UNA segment.
Know, in the UNA segment, there is no way that I know of, to indicate the use of any UNA6 suffix (as stated quite explicitly in the documents, the UNA segment has to be exactly 9 characters of length, see 8.3 Interchange formatting rules). That leads me to the conclusion, that you set the options for the created messages. I would not advise to use a UNA6 suffix, if you can avoid it. It might be nice for humans to read the message, but it does not belong there and is not useful for the machine to read.
If the receiving program has no option to allow optional occurrence of CR/LF, and you can not avoid a mix of those to kind of messages, I see no other way for you other than somehow insert a small program that gets rid of the CR/LF.
The most important principle is of course, to make the sending and the receiving program talk in the same syntax, otherwise it can't work. The same thing goes for the problem with the decimal separator. As of Syntax rules, 10.1, either the comma or the dot is allowed, which is a quite loose definition. If you want to be on the save side, send an UNA segment, specifying which one you use, and then only use that one.
I'm not really sure, how much this helps you with the specific problem, as it might be a thing that's only a question on how to configure biztalk, but I thing some background information should be useful.
I am writing an application which uses the DCM MKDIR, We save our images in little bigger name, but when I am trying to use the DCMMKDIR application, which is asking me to input file name max 8 characters.
Presently, I am planning to rename my Images starting from 1 to N. But remapping these images to known names(on the disk) will be bit difficult(I feel).
are there are any other methods/process to achieve the same.
The restriction of the filename to eight characters is derived from the DICOM Standard to ensure compatibility with applications that support e.g. only ISO 9660 as a file system for CDs.
About the naming you can have a look at the specifications the german CD Testat (http://www.dicom-cd.de/docs/DRG-RequirementsSpecification-2006.pdf). As a vendor you can be certified to conform to certain standards for interoperability of patient CDs which is currently the most common usage of DICOMDIRs.
The DICOMDIR file generated by DCMMKDIR is mainly a kind of index to tell an application, what DICOM files in a certain directory exist and this kind of file structure is usually more common for transfer media.
It is very common to use subdirectories to circumvent the restriction on max 8 length filenames. For example, a file could be 20110331/183421/000001 which would identify it properly with date, time and index without exceeding the somewhat arcane filename limit.