on 2015 Sep 08 8:30 AM
I have an ECC to JDBC scenario. The record has seventy fields and there are around 3000 records in one payload sent from ECC.
At times, the ECC is sending more characters in a field and due to that the entire payload is failing.
For ex: the third field has character length of three fields. If ECC sends four characters it will fail. The JDBC receiver adapter doesn't show which field has more characters and the interface just fails. There may be upto 3000 records in the payload.
Is it possible to make sure that the records with proper data can be processed in JDBC receiver adapter and the error ones fail?
Is there any work around available?
Hi Harish,
Go to DB and check the fields lengths and types. Later set you sender schema with this characteristics, then the sender ECC proxy will have these restrictions.
Regards.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
HI Harish,
If I set that limit in DT, will the entire payload fail in PI mapping or the remainging records pass through it?
The question is no exact, they will not can generate the payload on first. However, if you think, they can control better this problem and to avoid to generate the data erroneously.
Regards.
Hi Harish,
Even I agree with Iñaki Vila
It is always better that we restrict the processing of erroneous records on source itself. It would be good if the decision of excessive length is taken care in ECC proxy.
Also, in sender agreement you can set XML Validation so that any error record even if it is sent from ECC is not even sent to JDBC atleast for known restrictions as tracing back the error records and re-processing them is more troublesome from JDBC perspective.
Thanks,
Amit
Hi Amit
The problem is we are getting payload with thousands of records. If one record also has more chacracters than alowed, then the entire payload fails.
If I use this validation, will the remaining records be processed?
Say, ECC sends 100 records in one payload. There are three records with extra charcaters. Will the 97 records in the payload go through?
Regards
Harish
I was searching the answer for your question, if everything will fail.. Yes
Whole mapping will fail if a single record is unable to be validated by the schema check this
you have to enable the validation by adapter option in the sender adapter otherwise there isnt any use of maxlength and it is not safe as it may result in unwanted failures better go with substring
Hi Harish,
Say, ECC sends 100 records in one payload. There are three records with extra charcaters. Will the 97 records in the payload go through?
No, but XML validation would atleast give you the details of possible record which is failing. Morever, still you would have the message in failed status in PI which can be edited for erroneous record and batch can be re-processed from PI.
However, I would still recommend to make validation in proxy code of ECC to truncate excessive characters for fields due to which database update may fail and when you do this you are actually reducing the frequency of redundant KNOWN errors.
I also agree with solution proposed by Vinay of trncating extra characters in PI by using substring but standard substring function sometimes doesn't behave as expected so my recommendation is for handling the validations in proxy code to extent possible.
Thanks,
Amit
Hi,
>>Is it possible to make sure that the records with proper data can be processed in JDBC receiver adapter and the error ones fail?
Could be possible, but it depends whether u are using SP or Insert/Update statement?
Check my reply in this thread
Thanks
Amit Srivastava
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
set the logSQLStatement parameter to "true" in he advanced adapter properties of jdbc adapter then you can see the query in RWB and the exact place where it fails.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
73 | |
10 | |
9 | |
8 | |
8 | |
6 | |
6 | |
6 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.