Use of "Error Handling" Tab in InfoPackage Update Tab?

Hello All
I want to know the Use of "<b>Error Handling</b>" Tab in InfoPackage Update Tab?
Options in this tab are like
1.No Update,no reporting
2.Valid records update,no reporting(request red)
3.Valid records update,reporting possible(request green)
Terminate After No.Errors _________
4.No Aggregation Allowed
Will anyone tell about this in detail?
Many Thanks
balaji

Hi,
No update, no reporting (default):
If errors do occur, the update of the entire data packet is canceled. The request is not released for reporting. However, the records check continues.
Updating valid records, no reporting (request red) :
This option enables you to update valid data that is released for reporting only after the administrator has checked the incorrect, not updated records, and has manually released the request (by a QM action, meaning setting the Overall status on the tabstrip Status in the monitor).
Updating valid records, reporting possible :
The valid records can be reported on immediately. Automatic follow-up actions are also carried out, such as adjusting the aggregates.
With option a) the incorrect records are marked in red in the PSA maintenance. You can display the relevant error messages amodally, edit the records, and update the request manually. If it was not possible to write into the PSA (hierarchy or transfer method IDoc), an application log is written instead.
With options b) and c) a new request that is only read into the PSA is formed from the incorrect records. Here you can edit the records of the new request in the PSA and start the update manually.
For more information please refer the URL below.
http://help.sap.com/saphelp_bw30b/helpdata/en/05/bb223905b61b0ae10000000a11402f/frameset.htm
Regards,
K.Manikandan.

Similar Messages

Option for error handling for DTP, ' no updata, no reporting" and "deactiva

Hello Gurus,
     option for error handling for DTP, ' no updata, no reporting" and "deactivated" , please give some explanation and instance for them?
Many Thanks,

On the Update tab page, specify how you want the system to respond to data records with errors:
                            a.      No update, no reporting (default)
If errors occur, the system terminates the update of the entire data package. The request is not released for reporting. However, the system continues to check the records.
                            b.      Update valid records, no reporting (request red)
This option allows you to update valid data. This data is only released for reporting after the administrator checks the incorrect records that have not been updated and manually releases the request by setting the overall status on the Status tab page in the monitor (QM action).
                            c.      Update valid records, reporting possible
Valid records can be reported immediately. Automatic follow-up actions, such as adjusting the aggregates, are also carried out.
http://help.sap.com/saphelp_smehp1/helpdata/en/42/fbd598481e1a61e10000000a422035/content.htm
Hope it helps.
rgds, Ghuru

Is there a way to find out that a variant is of type vt_null, without using an error handler?

i am using an persistant ado-recordset. some fields may return a variant of type vt_null (sql-null value).
i want to figure out if a field contains a null or an empty string. when i checked the "view type" at a variant control, i see that labview correctly recognize a null value.
making a compare with "not a refnum/number/..." does not work. checking against a null string also don't work.
i used "variant flatten string" and "flatten string" but there is no difference between a field containing data and a null field (the type string tells me that is a reference to the variant, neither function 'flatten' the refrenced variant)
"varaint to data" results in an error, whe
n used with lv-native datatype and trying to convert a null-value. but the function has to return a variant, so using an error-handler is not an option. (converting variant-null to variant-data does not produce an error)
i also tried to get the "attribute" "value type"; it is not accessable with this function, like "attribute" "value".
is there a way to extract the variant data-type from a variant? or any other soloution to find out that a variant carries a null-value?

Hi,
sorry, i got no idea how to get the datatype of a variant, but there are properties "ActualSize" and "Type" of the ADO Field-Object. In case of an empty field the ActualSize is zero. Maybe you can use that. See VI below.
best regards
chris
Best regards
chris
CL(A)Dly bending G-Force with LabVIEW
famous last words: "oh my god, it is full of stars!"
Attachments:
DB_Test.vi ‏67 KB

No 'Handle Duplicate records' in update tab

Hi,
I've a DTP from ODS/DSO to ODS/DSO and I got a Duplicate record error, which I find rather strange for standard ODS/DSO. I read in the help and within these forums that it can be fixed with the 'Handle Duplicate records' checkbox in the update tab. Trouble is that there isn't such a checkbox in our BI7 SP15 installation.
Any suggestion on the reason for that and how to fix this and more important on how to get rid of the duplicate record error (and the reason why it's occurring)?
Many thanks in advance
Eddy

Hi Eddy,
I am confused -:)
Have u tried by checking or by unchecking..
My suggestion is to try by selecting the setting unique data records...
Cheers
Siva

Using code interface node with dll crashes LV 2011 but not LV 8.6... using max error handling does nothing

Hi all,
I'm having a peculiar problem.
I inherited a project saved in LabVIEW 8.6. The project must use of particular dll that was built a few years ago. The original developer and source code for this .dll are long gone. The very core logic exists, in the form of embedded C code, and that's it. The .dll is called through a Code Interface Node in LV 8.6 and this setup manages to "work". Howver, running the VI that calls this .dll in LV 2011 causes an "insta crash", as in, no "program has stopped responding". Error message pops up, then all LV windows close.
It's very similar to that described in here:
http://digital.ni.com/public.nsf/allkb/D84C9775ABD921CF8625772A005CA50C
but this KB says to try putting the amount of error handling to maximum. I tried that, but it didn't help.
Using the "Debug" option allows me to run the just-in-time debugger with CVI 2010, which then proceeds to say this:
Finally, I manage to get this out of it:
FATAL RUN-TIME ERROR: Unknown source position, thread id 0x000012D4: A non-debuggable thread caused a 'General Protection' fault at address 0x00000000.
I don't think that really helps at all, but it's there.
Here is the function prototype of the .dll:
void _inputPM@224(uint8_t arg1, uint16_t arg2, uint8_t arg3, float arg4, float arg5, float arg6, float arg7, float arg8, float arg9, float arg10, float arg11, float arg12, float arg13, float arg14, float arg15, float arg16, float arg17, uint16_t arg18, uint16_t arg19, uint16_t arg20, uint16_t arg21, uint16_t arg22, uint16_t arg23, uint16_t arg24, uint16_t arg25, uint16_t arg26, float arg27, float arg28, float arg29, float arg30, float arg31, float arg32, float arg33, float arg34, float arg35, float arg36, float arg37, float arg38, float arg39, float arg40, float arg41, float arg42, float arg43, float arg44, float arg45, float arg46, float arg47, uint16_t arg48, uint16_t arg49, uint16_t arg50, uint16_t arg51, uint16_t arg52, float arg53, float arg54, float arg55, float arg56);
(never seen a function take 50 input params like that (wouldn't you use a struct? array? something? But I digress, and I don't know anything about .dlls...))
I do have a ".lib" and a ".cdb" file with the same name as the .dll, but those also looks like some kind of compiled file.
I'm sure the answer I'm going to get is that there is no way of telling what's really going on without .dll source code. I'm hoping against hope that there may be another way or hack.
Any ideas? Thank you for you help.
Regards,
Mark G
Solved!
Go to Solution.

MarkCG wrote:
Changing the call library node to stdcall (WINAPI) did the trick! No more crash. Thank you very much!
I haven't run LV2011 on windows XP, only on windows 7, so I don't know if that makes a dfference. But The call type makes no difference when using LV 8.6 on the same machine, however.
Now I've got to make the .DLL run corretly on a compact fieldpoint.... and avoid crashing IT.
Thank you for the help all!
Well, the DLL did work fine in LabVIEW 8.6 because earlier versions of LabVIEW automatically proceeded to change the calling convention to stdcall, if they noticed a function name decoration of @# (# = number of bytes passed on the stack) appended to the name. This is the default naming decoration for stdcall functions used by VisualC. However this decoration can be overwritten with linker switches, other compilers don't use them always in the same way, and most likely there are in the mean time compilers out there that can produce such decorations also for non stdcall calling convention. So this automagic trickery was removed from newer LabVIEW versions.
I do think it could be considered a bug in the code that upgrades LabVIEW VIs, that it uses the calling convention that is configuerd in the dialog, instead of the calling convention earlier LabVIEW versions used automagically, but it is an esoteric corner case.
What Compact Fieldpoint controller do you have? If it's anything newer than 20xx or 21xx forget it. The 22xx controllers use a PPC CPU and VxWorks operating system and can never get a Windows DLL to operate properly. If it is a 20xx controller it's still highly likely that DLL can not even get loaded into LabVIEW as it likely relies on other runtime libraries and possibly Win32 APIs not present in the Pharlap ETS runtime kernel used on those controllers.
There is a tool to check a DLL for incompatible imports that are not present on specific ETS RT systems. And this list summarizes the RT system used on the various NI controllers.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Error handling in BI7.0

Looking for a functionality which we have in 3.x infopackage level.In infopackage of 3.x we have the concept of error handling by going to update tab and we will give the error handling wherein we have the option of giving few records and selecting 'valid reccords update ,reporting possible(request green)'.
How do we do this in BI 7.0 in a DTP ..
Thanks in advance.

Hi Kumar,
You can find the details in SAP Help:
On the Update tab page in the data transfer process (DTP), the error handling settings allow you to control how the system responds if errors occur in the data records when data is transferred from a DTP source to a DTP target.
These settings were previously made in the InfoPackage. When using data transfer processes, InfoPackages only write to the PSA. Therefore, error handling settings are no longer made in the InfoPackage but in the data transfer process.
Settings for Error Handling
For a data transfer process (DTP), you can specify how you want the system to respond when data records contain errors. If you activate error handling, the records with errors are written to a request-based database table (PSA table). This is the error stack. You can use a special data transfer process, the error DTP, to update the records to the target.
Temporary storage is available after each processing step of the DTP request. This allows you to determine the processing step in which the error occurred.
"Repairing" with Error DTP
You create an error DTP for an active data transfer process on the Update tab page. You run it directly in the background or include it in a process chain so that you can schedule it regularly in the context of your process chain. The error DTP uses the full update mode to extract data from the error stack (in this case, the source of the DTP) and transfer it to the target that you have already defined in the data transfer process.
For more, please have a look at this Link: [BI 7Handling of Data Records with Errors|http://help.sap.com/saphelp_nw04s/helpdata/en/42/fbd598481e1a61e10000000a422035/frameset.htm]
Cheers,
Habeeb

Use ABAP Routine in Selection Tab of Infopackage

I am trying to use the ABAP routine in the InfoPackage SELECTION Tab to "EXCLUDE" a value. For example, I want to load all the Material types, except ZUN1. But, when I write in the ABAP, l_t_range-sign = 'E' instead of 'I' or l_t_range-option = 'NE' instead of 'E', I get an error saying these values are not permitted.
Is there any way to exclude any value from Selection in the InfoPackage?
Regards,
Milind Vad

Hi dear and welcome on board!
You have two options:
include everything you want in your IP
load everything and exclude what you don't want in the start routine in transfer rules
No other ways...
Hope it helps!
Bye,
Roberto
...and please don't forget to reward the answers...it's THE way to say thanks here !

Using AIA for Error Handling. Logging and Notification Services

hi,
In our project we usie OSB and BPEL for integrating different applications.
There is a suggestion that we should use AIA to just use the Error Handling, Logging and Notification services from AIA. I am not sure about this use case, as most of these services mentioned can be replicated in BPEL. Except for the AIAAsyncExceptionHandling BPEL process, i guess all other functionalties provided by AIA can be easily developed in BPEL or OSB alone.
However, would like to hear from you guys about this particular use case. Is it advisable?

Hi,
It's an issue with 10.1.3.4 OBIEE. (whem using IBM LDAP)
References
BUG:7363517 - INTERNAL BI FAILURE ON STARTUP
They issue can be resolved by setting LD_PRELOAD=/path/libibmldap.so
Here are the steps:
. sa-init.sh
export LD_PRELOAD=/path/libibmldap.so

Can error handling framework use fault policies and BPEL catch blocks

As part of an integrated customer solution that makes substantial use of SOA Suite (including OSB, BPEL, Mediator, etc) we are in the process of designing an “Error Hospital” subsystem to expose a web service API specifically for BPEL services and/or the OSB layer to call whenever they encounter an exception which they cannot handle so that the appropriate user is notified of the error (via email) and the error is recorded (in an appropriate common fault format, with error codes elaborated into more meaningful descriptions, etc) within OEM, immediately prior to returning the exception to the caller.
The problem we have experienced in our design is as follows:
•     We have an error handling service to be called, inside the BPEL catch blocks, when an error occurs to notify the appropriate user, via email, that an error has occurred;
•     We also use the error handling XML fault-policies so that we can recover from an error using OEM (via human intervention);
•     The error service needs to be called before the process is suspended (waiting for human intervention) so the email notification and error message formatting occurs BEFORE the recovery action. Unfortunately the fault policies trigger BEFORE the error handler is able to transform the error into the appropriate format and notify the user so the error recorded is not the reformatted one and the user is never notified.
The key question is how can a BPEL, upon catching an exception, invoke the error handling service and AFTER that send the error to OEM (and have the process suspended).
It seems the two mechanisms "cannot play nicely together"

As part of an integrated customer solution that makes substantial use of SOA Suite (including OSB, BPEL, Mediator, etc) we are in the process of designing an “Error Hospital” subsystem to expose a web service API specifically for BPEL services and/or the OSB layer to call whenever they encounter an exception which they cannot handle so that the appropriate user is notified of the error (via email) and the error is recorded (in an appropriate common fault format, with error codes elaborated into more meaningful descriptions, etc) within OEM, immediately prior to returning the exception to the caller.
The problem we have experienced in our design is as follows:
•     We have an error handling service to be called, inside the BPEL catch blocks, when an error occurs to notify the appropriate user, via email, that an error has occurred;
•     We also use the error handling XML fault-policies so that we can recover from an error using OEM (via human intervention);
•     The error service needs to be called before the process is suspended (waiting for human intervention) so the email notification and error message formatting occurs BEFORE the recovery action. Unfortunately the fault policies trigger BEFORE the error handler is able to transform the error into the appropriate format and notify the user so the error recorded is not the reformatted one and the user is never notified.
The key question is how can a BPEL, upon catching an exception, invoke the error handling service and AFTER that send the error to OEM (and have the process suspended).
It seems the two mechanisms "cannot play nicely together"

Error handling in Info Package

Hi,
I am flexibly loading master data into an Info Object (0DPM_DCAS) Info Provider.The delta loads occur on a daily basis.It is fed from two data sources serially in a process chain.
My concerns are regarding load failures.
What ideally should be the "Error handling" setting in the info package? "No update,no report / Valid update,request red / Valid update,request green"? What might be the implications of each on a long term basis?
Also, if a delta load fails from one of the data sources do I need to set the QM status manually to green to make the subsequent loads go through? If so how do I obtain the data for the failed request?
How safe is it to manually change the QM status?

Hi Avishek,
The Error handling mechanism works whenyou load to PSA and subsequently update the data target (InfoObject in your case). This is provided for in cases where you know that there is some junk data that will be extracted, and this can cause a load to fail in BW. Eg. you are loading around 90,000 material values and even if one has an extra char, the whole load will fail. To prevent this, you can use error handling. In Valid update,request red the correct records are updated and incorrect are left behind, but the data is not released for reporting. Using the Valid update,request green option, the correct records are updated and are also available for reporting. You can later edit the incorrect records (stored in PSA as a separate request) and update them to the data target.
If a load fails, never set it to green else you will miss out on the next delta. Always make sure that it is red and then delete it or request the next delta. Changing the QM status is quite commonly done, but it is important to be very careful.
Hope this helps...

Error Handling of Sync/Async Bridge

Hello,
does the error handling of an sync/async bridge behave exactly as the error handling of a single sync sender?
Details are the following:
I would like to use the error handling capabilites of a sync step, so that the error handling branch is executed when a permanent pipeline error occurs (this is only possible with a sync send step). However my receiver system can only communicate asynchronously. So the question is, if the first asynchronous send step fails (e.g. error in pipeline processing) normally no error is triggered. Would this be different if the error occurs withing a sync/async bridge?

Hi Abhishek,
Thanks for the immediate reply.
The scenario is
ERP <---WS/SOAP--->PI -----WS /SOAP of 3rd party---> 3rd Party system (X).
PI <------- WS of PI
X posts the data to a backend. THe system X then picks some processed information. This system is not capable of sending the response synchronosly. It can post this data to PI once the data is available. Now PI needs to take this data and post it to the WS request from ERP.
Hope I have provided some clarity on the scenarion..
Thanks again.
Bharathwaj
Edited by: Bharathwaj on Aug 11, 2009 4:59 PM

Error handler for event based messaging framework

I've been very interested in using the event based messaging framework (described here http://forums.ni.com/t5/LabVIEW/Community-Nugget-2009-03-13-An-Event-based-messageing-framework/td-p...) for my next large application.
My main concern is the fact that it seems like typos would be very difficult to debug since you need to ignore unknown commands to make this system work.
To solve this problem I've been considering the idea of having a single message error handler VI which will store all valid commands and check all sent commands to see if they are valid. Each VI would send out a register message on startup with their name and all messages they can send and receive. The message error handler would store these and then check all future messages to be sure it is a valid message, throwing an error if it is not.
My basic problem is this: for this to work the message error handler VI would have to be started before any messages are sent so that it can capture all the register events. If this is a VI that will be continuously running the entire application how can I ensure it starts first since I cannot wait for it to complete? (I.e. the usual method of running an error out wire or using a sequence structure will not work since everything will then wait for it to complete which will not happen until the program is ready to shut down)
I'm assuming the answer might be to use an asynchronous call but I'm not very familiar with this method.
Any help is appreciated. Thanks.

Could you just use the error handler as a subVI inside a case structure that is only called when you have new message to be checked? I'm not sure I understood the exact functionality you are looking for, so sorry if this does not apply.
Zach P.
Product Support Engineer | LabVIEW R&D | National Instruments

Forward Error Handling - File interfaces?

Hello Experts,
Can we use Forward Error Handling (FEH) for implementing error handling in File Interfaces ?
Like for simple Application Server file interfaces, if something goes wrong during the process of writing/reading a file on App Server, can we use FEH for showing the log?
I know it is a concept used for PI...so we want to know if it can be used for file interfaces as well? Just want to keep similar approach for error handling and logging (for both PI and File Interfaces).
Thanks.

Edit 1 May 2015: Added inbound
Just a slight correction.
FEH is used in the ABAP backend systems and are only for asynchronous inbound proxy interfaces. It is not available for sync proxies, IDocs, BAPIs. Neither is it available for any error handling on the PI system itself.
PI/XI: Forward Error Handling (FEH) for asynchronous proxy calls with the use of Error and Conflict Handler (ECH)
Message was edited by: Eng Swee Yeoh

How to implement general error handler in labview projects

Thanks,

Hello,
You may also find these links useful:
Custom Error Handling In LabVIEW
http://zone.ni.com/devzone/conceptd.nsf/webmain/de4f036f22c4b9f286256fee0010b6fd
LabVIEW Introduction Course - Six Hours (has a section on error handling)
http://zone.ni.com/devzone/learningcenter.nsf/03f7c60f17aad210862567a90054a26c/55974411828f779086256...
Hope this helps!
Charlie S.
Visit ni.com/gettingstarted for step-by-step help in setting up your system

Question about error-handling in PL/SQL

Hi friends,
I would like to know if there is a way for error handling for insert and update statements in PL/SQL???
Like when for example an insert fails!
thanxx
Schoeib

You should get a book about such fundamentals!
This is not an online course...
begin
insert into emp values(...);
exception
when no_data_found then
when others then
end;

Use of "Error Handling" Tab in InfoPackage Update Tab?

Similar Messages

Maybe you are looking for