dkuehner |
Member |
|
|
|
|
None Specified |
|
Monday, June 8, 2009 |
Friday, November 22, 2013 4:09:31 PM |
19 [0.10% of all post / 0.00 posts per day] |
|
I've sorted this out. I had to do a double mapping. Once to separate out the various node levels to elements with different names, then a second time to map everything to the final format I wanted.
Then I had to modify the software that runs things to first define a second desired xslt and then to do the 2 transforms one after the other.
Oh well. Not the preferred solution, but it gets the job done.
|
I am using mapforce 2009 (I know, this is old, but it works for everything else. Hopefully I won't need to upgrade to resolve this)
I have an xml message that I want to transform that has a set of repeating elements. One of which contains what I'll call header information and the rest contain detail information. I want to end up with a set of new elements, one for each of the detail elements, plus I want data from the header element to map into each of the detail elements.
For instance take this:
<document> <repeating> <type>header</type> <id>1</id> <data>headblat</data> </repeating> <repeating> <type>detail</type> <id>2</id> <data>detailblat1</data> </repeating> <repeating> <type>detail</type> <id>3</id> <data>detailblat2</data> </repeating> </document>
and map to this:
<newdocument> <repeating> <type>detail</type> <id>2</id> <data>detailblat1</data> <headdata>headblat</headdata> </repeating> <repeating> <type>detail</type> <id>3</id> <data>detailblat2</data> <headdata>headblat</headdata> </repeating> </newdocument>
I have used a filter based on the type=detail to end up with everything correct, except that the headdata is not filled in. This is because the initial repeating element has a type <> detail so it is just ignored.
I'd like to pick up the data from the type=header element and put it into each of the output repeating elements. Note though that I can't change the structure of the input xml and I'd prefer not to do this in 2 steps.
Does anyone know how to do this?
|
When I do a database compare and then ask for a merge script to be created, the result is unusable without some manual processing. There are blank lines inserted inside of the data portion of the sql statements in the merge script. This seems to happen when I have a new line in my data. Instead of just outputting the data, it adds some extra lines and spaces.
This is shown below around the "from EMP". My data contains sql statements which are stored in a database table. It is in this data that the extra lines are generated.
Does anyone know why this is happening? Is there a setting I have missed that could control this?
-- region merge from dbo.CCNativeDbCommand to dbo.CCNativeDbCommand INSERT INTO [NDI_BKP].[dbo].[CCNativeDbCommand] ([BeanId], [Phase], [NodeLevel], [Sequence], [ApplyOrder], [Condition], [Type], [Command], [UserId], [UpdateXml], [Active]) VALUES ('CUSTDbInputNative', 'Main', 'Head', 374, 63, '', 'Sql', 'select EMP_EmployeeID as CUS_EmployeeID from EMP where EMP_RecordID=''%%HPATH:con_CreatorUSR%%''', '', 1, 1) ; -- endregion merge from dbo.CCNativeDbCommand to dbo.CCNativeDbCommand
|
I am doing a database diff, and I get a message "Execution Failure" beside each table on both sides of the compare in diffdog.
I am dealing with 2 databases, one is just a copy of the other and I have just a couple of data differences between the two.
Both data connections use ODBC to a SQL Server database.
Any ideas?
EDIT: SOLVED. This was a permissions problem on the copied database. (copied it twice and the second time forgot to set the permissions. D'oh)
|
I can understand if you didn't know of any tools etc. to help with this, but what you suggest is obvious. In fact it is so obvious that I mentioned that strategy in my question.
If you had read the question, "simply map"ing it is complex since 997's need to include parsing errors. These errors are not available to "simply map" since they are generated by the EDI to XML java code which does not actually create 997's.
So to "simply map" the errors, I will need to accumulate them in java (something that the generated Parser.java does not do) and programatically make them available in some fashion to be mapped. Hardly "simple".
|
Excellent answer - if only it were true.
The complete extent of the "Extensive Help" about this is the following:
Request acknowledgement: Default yes
Completely useless
|
If I generate java code from a mapping, there is a com.altova.* package generated with various java classes. Is this a standard package, or will the classes change depending on the mapping in my mfd file the next time I generate code from the project?
The reason I ask is that I need to modify some of the classes in com.altova and I want to know if this code will change the next time I generate some new java code for the mapping?
|
In the properties of an EDI component in Mapforce, there is an option "Request Acknowledgement" - Yes/No
What is this? Is this just used as a default setting for the Acknowledgement Requested field in the ISA record? Or is it something to do with the generation of 997 Acknowledgements?
|
Thank you.
|
I am doing EDI mapping to XML using MapForce and generating java code.
Parse.java seems to do a fine job of finding errors in the EDI and then prints those errors to standard out. What I need to do is to map those errors back into a 997 acknoledgement to send a success or failure message to the sendor.
My thought is to replace the exception handling in Parser.java and then build code to create the 997, however this will be a lot of work and it means changing the generated com.altova.* classes.
It seems to me that every single person who accepts EDI documents must have dealt with this same problem. Are there any tools or libraries that handle this? Is there anything in MapForce that does this automatically since it must always be done?
Thank you for any information.
|
|