Hi RMG, Any advise on 6.5 SP3? Thanks, Capri_lak
“same taskIds on all the 4 servers” → I am still unsure how come they are same esp in a non-clustered env…Can you try to recreate on single IS and check it?
Hi, we are getting an 4060 210 EDI from customer which is having record delimiter as …(3 dots) But when is getting submitted to TN is it getting replaced as little square box in the content of TN console.This is not causing any problem while splitting the documents. But just trying to maintain a sync between the data sent by customer and view in the TN.What I understood was when that special delimiter(…) is coming, the webMethods EDI is not able to recognize and replacing it with small square box.Also I realized the current setting for charset in our environment is as follows:ISO-8859-1. Based on my research,I realized that we should be using charset=UTF-8 to get that delimiter displayed. Is there any way I can populate it? I mean any place specifically to take care of it and get it recognized.I am also little bit concerned of not touching the existing charset:ISO-8859-1 to effect the current integrations. If there is any other way around I would like follow.Could anyone please advise when you get a chance. Thanks, Capri_lak.
By default it should be charset=UTF-8 (XMLdata or EDIdata processing) not ISO…It shoudn’t effect env and test it.
HTH
RMG
It is not replacing anything. As we’ve discussed in our email exchanges, it is a display concern only. The character used for the delimiter in ISO-8859-1 is simply a non-printable character, and is displayed as a square box.
Unlikely. It depends on what encoding the partner used to send the EDI data. Most likely it is ISO-8859-1, not UTF-8. In any case, processing the incoming data you’ll want to explicitly set the charset to use when the bytes are read–the charset must match what the partner used to encode the bytes. Even if the default charset of the JVM is UTF-8, the charset of the data will still be ISO-8859-1 (if that’s what the partner is sending) and that delimiter will still display as a square box.
The out-of-the-box default charset is UTF-8. But that can be changed. I’ve seen at least one installation that changed it to ISO-8859-1 to make bytesToString/stringToBytes service calls easier by not needing to explicitly set the encoding. This can be useful when the majority of interfaces use ISO-8859-1.
Changing the default charset of the JVM can have serious impact on existing integrations. A change to it is not something to take lightly–if assumptions were made about the default charset then changing it can break existing integrations.
I agree with you Rob.,…out-of-the-box default charset is UTF-8 and not ISO as I indicated above also…and use the service calls that you mentioned for convertion.But I have not seen installation that changed to ISO charset based default…
Hi, Currently we have a partner, we do send 856 to the partner. As a part of new requirement, we are receiving 410 from the same customer.When the document gets processed in TN, In Transaction Analysis I do see x12 group/x12 envelope processing status as Done W/Errors. which is displaying the error msg as follows: Expected a control number of 2, but received 1. This is a duplicate control number. [EDIFTN.000010.000248]. This is not causing any issues as data is getting parsed the way it is supposed to be.But from trouble shooting point of view it is displayed as Done W/Errors which is misguiding us.I am just wondering, since it is an existing partner, the control numbers are some how getting used again.Is there any way to update/configure the control numbers that way they don’t overlap and avoids this issue.Could anyone please advise. Thanks, Capri_lak
Yes you can update/configure control numbers(increment order partner specific during add envelopes from table) using EDI Module services /WmEDI home page (Manage control numbers) partner specific (sender/receiver/standard/version combination).
HTH,
RMG
HI, I am trying to add the attribute @system type XSL information below the @version to the XML. I am just wondering Do I need to use any standard bulit in services or Do I need to hard code the value. Actually I did hard code and it is not getting generated. Could anyone please advise. Thanks, Capri_lak.
Did you created the XML doc structure using DTD? It will create those elements for you and can hardcode it. Alternative is use replace service and replace the starting tags that you want with.
for example:
<?xml version="1.0"?>HTH,
RMG
The only way to change the XML declaration (the <?xml…> line) or to add processing instructions (the <?xml-stylesheet…> line) is to create the lines in your service and concatenate them with the XML document string. Specify false for the addHeader parameter of the documentToXMLString service call.
You can hardcode the steps to create the desired prologue (the declaration and processing instructions) or you could use some sort of configuration file or DB record and read the strings from there.
I believe he is actually looking for adding attributes @SYSTEM not the xml tag version portion (addHeader=true) etc…
Hi RMG, Exactly I am looking to add attributes @SYSTEM not xml tag version portion. I am just wondering how and which replace services(mentioned in the early post) I do need to use achieve the desired output. Could you please advise. Thanks, Capri_lak.
How exactly you want that tag/attributes to be appeared? Do you have the hardcoded values to put?
Is it similar that you are looking for
In the Replace service: set the
searchString <?xml version="1.0"?>
replaceString <?xml version="1.0"?>
Hope you got it now…
HTH,
RMG
Hi RMG, Thank you very much. It worked…I really appreciate all your help. Thanks, Capri_lak.
SYSTEM is associated with the DOCTYPE [strike]processing instruction[/strike] declaration. Since the post mentioned XSL I assumed the desired result was to get the xml-stylesheet processing instruction placed into the prolog:
<?xml version="1.0"?>[FONT=monospace][/font]<?xml-stylesheet href="example2.xsl" type="text/xsl" ?>
As opposed to:
<?xml version="1.0"?>[FONT=monospace][/font]
In either case, if these lines are desired at the top of an XML document they need to be generated by FLOW steps and then that string concatenated with the resulting XML document string.
[Edit]: Or a replace step can also do the trick, as rmg suggests.
Agreed with you Rob…generated by FLOW steps (should be created those doctypes from DTD) is the better solution and force replace is just a quick alternative as long it works…
Hi, we created the IS document types and did all the mapping.As a part of new requirement business team is asking me to change(rename) the Header in this e.g. I used now they want to replace it with . But when I went to the original Document type and renamed it didn’t work meaning, it has been renamed to partnernameInvoice but it came as a new document in the Original document type as all the mappings have been done under Invoice document in the Main document type. If that is the case, I am just wondering DO I need to all the mapping all the way from scratch which is going to be weeks of work.We are using IS 6.5 SP3 version.Could anyone please advise. we are kind of little bit concerned as we already have some partners in production which I am wondering Do I need to do all the mapping again? Thanks, Capri_lak.
Refactoring things in Developer is very limited. Indeed, it really only supports renaming services reasonably.
Renaming fields in a document type is to be avoided. If it is an arbitrary change (I sincerely doubt it is a “requirement”) then I’d offer that you can easily convince them that redoing all the mappings is more risk/work than the change is worth.
If you already have partners in production using this document type and naming, then such a change would really need some serious justification.
You could use search and replace using a text editor to modify the flow.xml files–but this can be risky too.
Another option to consider is instead of changing the name of the root element, add an attribute to the root. becomes . Perhaps that would fulfill the desire?
[Edit] Forgot to suggest: you should create new threads for new topics instead of covering multiple topics in a single thread.