Node taPMTransactionInsert not found in PMTransactionType
If you need to restrict out an entire row, you need to do that at the data source level.
You can change your data source to an ODBC connection and select text file as the ODBC Type. Then use SQL syntax to restrict the rows out.
Once Smart Connect has a data row then it needs to process that row.
What is the point/use of a restriction?
From the manul: "Note: scripts entered into the restrictions window should return true if the row is to be processed, or false if it is to be ignored"
That makes it sound like I can ignore an entire row in my dataset.
I know this is a pretty old post, but I ran into this issue as well in version 2018. The work around is easy enough, but why doesn’t restriction work as designed?
Julie & Edward,
It works exactly as designed – it restricts out that row entirely from being processed by that specific mapping.
The restriction for a “header node” that causes this error in GP eConnect is specific to eConnect and the eConnect assembly looks for the “header node” being included in the for the document types that it knows should have “headers”.
If this was a custom node (which you can create using Node Maintenance and adding in all the same mappings as the GP version) , then eConnect wouldn’t validate that header. And so I would assume you would get a blank document sent to eConnect which would be “successful” yet do nothing since no xml data to process.
Or if this was a “detail” node (such as ‘add distribution’ or ‘add line item’, etc) then it would just not be processed but since not the header row then you don’t get any kind of unhappy error messages from eConnect.
Lastly, f this was a CRM or Business Central map (of which this particular validation wouldn’t happen since eConnect specific) the restriction would work fine and again just remove that line from being processed.
So from a SC point of view, the Restriction code is working exactly as it should – don’t process this line. But you still have to abide by the rules of the destination.
So the rule of thumb on a GP destination.
If you plan to remove a line that will become part of a “header” node you would want to either:
1. remove as part of the source query (so SC doesn’t see/process it at all)
2. Use a “Before Document” script and use the same restriction code and have SC not process that document (since would be empty). Set the “on fail” to “Continue Processing” so that you don’t get errors in SC.
I don’t get it. For example, My restriction script fails for all my documents (I need to work on the date formats) but all the documents integrate. I want them NOT TO.
if _DATE = GBL_TODAY then
oops. Forgot to mention that my restriction Script is at the “before document” level.
OK I see what the prblem is. When pat mentions step 2 Set the “on fail” to “Continue Processing” . He means “Cancel processing”
Yes, thanks Dominic. Usually (and in this case) the correct wording is important.
If you would like to submit an answer or comment, please sign in to the eOne portal.