BW early delta initialization request failed

Dear all,
the early delta initialization request of a info package failed for the data source 2LIS_11_VAITM & 2LIS_18_I3OPER due to disk space problems (log overflow).
Is there a possibility to rerun the early delta initialization load without destroying the delta queue and without a new source system initialization? The job has to been already scheduled to push the data into delta queue and the delta info package was not started jet.
Regards
Edited by: Claudio Forte on Oct 11, 2010 11:22 PM

Hi,
Take a look on the information given in below links:
Re: Early Delta Intialization!!!
Re: Early Delta Initialization
Re: Early Delta Initialization
Re: Lo Extraction
Re: reg:early delta andinit delta with out data transfer
With rgds,
Anil Kumar Sharma .P

Similar Messages

How to Use Early Delta Initialization

Hi BW Experts,
We are in BI 7.0 Version. Only for Reporting we are using BI 7.0. For modeling, still we are using BW 3.1C only.
We want to use Early Delta Initialization. But this is in Disable Mode in our system
I am getting the following Messages:
"Extractors supporting early delta initialization are not available before plug-in (-A) 2002.1"
"You cannot execute an initialization simulation together with an early delta"
Please can anyone give me the suggestion.
Regards
Anjali

Hi,
you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the updating of data in the source system. You can only execute an early delta initialization if the DataSource extractor called in the source system with this data request supports this..Use the Early Delta Initialization indicator in the InfoPackage if you want to avoid a period when no updates can be made (no document processing and update) in the source system while the delta process is being initialized. In some applications (such as LO Cockpit), an update-free period is nevertheless needed to fill the setup tables. In such cases, the update-free time is merely reduced. If you want to carry out early delta initialization, the update in the source system can continue and the data can be written to the delta queue while the initialization requests are being processed. Note: DataSources that support early delta initialization are available as of the release Plug-In 2002.1. The field ZDD_ABLE (characteristic value = X) for table RSOLTPSOURCE (in BW) or ROOSOURCE (in the source system) indicates whether a DataSource can support early delta initialization.Not always on our systems an important downtime is possible in the initialization process during the reconstruction and the delta init request (just thinking when you need to ask a billing stop period...a real nightmare in some company !)
For this reason, as of PI 2002.1 and BW Release 3.0B, you can use the early delta initialization to perform the initialization for selected datasources (just checking in infopackage update mode tab if this function is available): in this way you can readmit document postings in the OLTP system as early as possible during the initialization procedure..In fact, if an early delta initialization infopackage was started in BW, data may be written immediately to the delta queue.
But, if you are working with the queued delta method, using early delta initialization function doesnt make sense: as described before, its the same method definition that permits to reduce downtime phase.
But leaving aside that, dont forget that, regardless of the update method selected, its ALWAYS necessary to stop any document postings (for the relevant application) during setup tables recompilation run

When are init entries done in source system?And early delta initialization?

Hi Friends,
Q1) When are the init entries done in source system?
If INIT entries are done when I run INIT that means:
If my setup job finishes at 6AM and I run the INIT at 1 PM will I loose all data between 6AM and 1PM?
If INIT entries are done when I run setup table i.e. when setup table load finish then
If my setup job finishes at 6AM and I run the INIT at 1 PM...it will load data till 6AM
and after that data would bere there in Delta queue. So, this is ok...as no loss of data.
Q2) I have read on help.sap that "With early delta initialization, you have the option of writing the data into the
delta queue or into the delta tables for the application during the initialization request in the source
system. This means that you are able to execute the initialization of the delta process (the init request),
without having to stop the updating of data in the source system."
Does this mean when I run INIT at 1PM, no V1 updates will happen for that DS in Source System?
If Yes, that means I should always (when users are online) run INIT with early delta initialization
during times when users would be online?
Thanks!

Hello,
You will find the answers to the questions that you ask and the correct procedure to follow in the SAP note 602260.
Best Regards,
Des

Early delta initialization

Hello Gurus,
What are the scenarios we use Early Delta Init.
Is it available for Logistics datasources.
Full points to right answers.
Thanks in advance.

hi BW,
check this
http://help.sap.com/saphelp_nw2004s/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/frameset.htm
Early Delta Initialization
With early delta initialization, you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the updating of data in the source system. You can only execute an early delta initialization if the DataSource extractor called in the source system with this data request supports this.
Extractors that support early delta initialization were delivered with Plug-Ins as of Plug-In (-A) 2002.1.
You cannot run an initialization simulation together with an early delta initialization.
yes, it's available for logistics - oss note 505700, you can cross check the infopackage.
hope this helps.
505700-LBWE: New update methods as of PI 2002.1
g) Early delta initialization in the logistics extraction:
As of PI 2002.1 and BW Release 3.0B, you can use the early delta initialization to perform the delta initialization for selected DataSources.
Only the DataSources of applications 11, 12 and 13 support this procedure in the logistics extraction for PI 2002.1.
The early delta initialization is used to admit document postings in the OLTP system as early as possible during the initialization procedure. If an early delta initialization InfoPackage was started in BW, data may be written immediately to the delta queue of the central delta management.
When you use the "direct delta" update method in the logistics extraction, you do not have to wait for the successful conclusion of all delta Init requests in order to readmit document postings in the OLTP if you are using an early delta initialization.
When you use the "queued delta" update method, early delta initialization is essentially of no advantage because here, as with conventional initialization procedures, you can readmit document postings after successfully filling the setup tables, provided that you ensure that no data is transferred from the extraction queue to the delta queue, that is, an update collective run is not triggered until all of the delta init requests have been successfully posted.
Early Delta Initialization

EARLY DELTA INITIALIZATION IN LO COCKPIT

HI EVERYBODY,
SORRY FOR ASKING A SILLY QUESTION --BUT I REALLY NEED AN EXPLANAITION
WHAT IS EARLY DELTA INITIALIZATION????(can we select this method the same way we do for Delta init)
I KNOW THAT BEFORE DOING DELTA WE WILL DO DELTA INITIALIZATION.
I HAVE READ A WEBLOG OF ROBERTO IT WAS WONDERFUL BUT I GOT STUCK WITH THIS EARLY DELTA INITIALIZATION. AND ABOUT DOCUMENT POSTINGS.
DOES THIS MEAN THAT BEFORE GOING FOR DELTA INITIALIZATION (i mean before filling setup tables ) DO WE NEED TO SHUT DOWN THE INSTANCE ON OUR OLTP --so no transaction data will be updated to the extract structure.
WHAT IS FREE DOCUMENTS POSTING PHASE
THANKS AND REGARDS
NEELKAMAL
Message was edited by: neelkamal moganti

You can find the option for Early Delta Init in the InfoPackage on the Update tab. Using this option, the source system update can continue and data can be written to the delta queue while the initialization request is being processed.
Early Delta Intialiation is the process in which we run the init of delta and load the delta queue in parallel.
Generally when we do Initialization we need to stop transactions in R/3 system till the initialization is completed if we do Early delta initialization we don't have to stop posting of transactions in R/3 even when we are doing initialization. Please see this for more explanation
Early Delta Initialization
With early delta initialization, you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the posting of data in the source system. The option of executing an early delta initialization is only available if the Data Source extractor called in the source system with this data request supports this.
Assign points if it helps...
regards,
ashok

Enabling Early Delta Initialization option for LO DataSource 2LIS_06_INV

Hi Guyz,
I want to enable Earlt Delta Initialization option for LO DataSource 2LIS_06_INV, as of now its greyed out.
please tell me if its possible or not, and if yes then please let me know the steps in detail.
cheerz,
raps.

hi,
Not all Data sources support Early Delta Initialization. Early delta initialization is done to capture the deltas when the initialization is being done between BW and source system (init with data transfer). As init with data transfer takes large time and during this time any records created will also be not captured so we do early delta initialization, also the same can be achieved by executing the init without data transfer and then loading a full repair request. The init without data transfer creats a time stamp and delta is generated for newly posted records.
regards,
Arvind.

Early Delta Initialization option in Production system

Hi Experts,
I have seen some threads related to Early Delta initialization in this forum. I have a question regarding this option.
To minimize the downtime/block users in the R/3 production system during set up tables fillup I would like to use the Early delta option. Please give your suggestions on the following procedure:
For Sales Orders, billing and Deliveries
1. Initialize Early delta in the BI system.
2. Go and fill setup tables
3. Do a full load to BI
4. Run delta job in R/3 (LBWE)
5. Run delta job in BI Info package
Do we miss any documents in this process for e.g. during set up tables fill up changes to existing documents or newly created sales orders.
I feel we won't miss. All changes will be reflected in Delta queue. And even newly created orders also will be coming to delta queue.
Please let me know if I am wrong.
Thank you.

Need Clarification on this thread,
According to my understanding, during the filling of set up table if a user does any posting, then the data available in BW will be incorrect.
am i right?
In your sequence the 4th step
4. Run delta job in R/3 (LBWE), this means you are using queued or unseriallized v3 update.
Early delta iniliazation essentially of no advantage because, as conventional initialization procedures, you can readmit document
postings after successfully filling the setup tables.
can anybody clear my doubt. is it possible during setup table filling user can post a document.
I know the documents will be collected in the queue. But the data loaded to bw will be incorrect right?
Regards,
Anand.
Edited by: araj123 on May 26, 2010 11:41 AM

Early delta initialization and update methods

Hi gurus
Can we use EDI with "queued delta" as update method?
If yes where we need to do that setting and if no then would you pl tell me which functionality we need to use in infopkg to load delta from R/3 with Queued delta as a update method?
Pl help to understand this.
Thanks

In the 'update' mode in your infopackage, if you see an 'early delta init' option, you can use it for that datasource (for queued or any other delta). This is where you choose to run an 'early delta init'.

Need for locking system for delta initialization (BW-R3-LO)

Hello all,
Could someone please help me with the following,
Please be kind, don't get impatient for the lengthy post
1. Do we need to lock the system (or posting-free the system) to do early delta initialization or not? If yes, please explain me how that work?
2. Someone somewhere mentioned that early delta initialization is not preferable compared to normal delta initialization, even though early delta initialization is advantageous. Why is that so?
3. Imagine, while scheduling Queued Delta Init or un-serialized V3 delta Init, if I choose certain end date and time (say, 10pm, 12-31-2007) for the records, then all the records till that point would be loaded to setup tables and all the records after that point of time will be moved to extraction queue or update tables. My question is, if this is true why would we ever need to lock the system during setup tables filling?
    If you say the records after that particular time and date (10pm, 12-31-2007) will not be collected in extraction queue and update tables, why don't we do the following
             a). say, I do full load with end date and time (10pm 12-31-2007)
             b). Next, I do delta init with start date and time (10pm 12-31-2007) (this time I lock the postings)
         If we do this way, we can actually reduce the down time of the system. Is my conclusion right?
         If you say it's not practicable as some transactions' saving time differs from time stamp and some transactions' delta is even measured by pointer.......if this is the case we can use Delta offset. What do you say about this?
4. How this scenario differs to early delta initialization?
Your responses would be greatly appreciated
Thank you

Hello,
1
>
curious maven wrote:
> Do we need to lock the system (or posting-free the system) to do early delta initialization or not? If yes, please explain me how that work?
No,you don't need to lock the Source System which is the advantage of Early Delta Init.
With early delta initialization, you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the posting of data in the source system. The option of executing an early delta initialization is only available if the DataSource extractor called in the source system with this data request supports this.
[Business Information Warehouse 3.0 Overview Presentation|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/9a0e9990-0201-0010-629b-dc2735cb9c81]
2
>
curious maven wrote:
> 2. Someone somewhere mentioned that early delta initialization is not preferable compared to normal delta initialization, even though early delta initialization is advantageous. Why is that so?
Early delta is not supported by all the extractors. See Lo Extraction
3
>
curious maven wrote:
Imagine, while scheduling Queued Delta Init or un-serialized V3 delta Init, if I choose certain end date and time (say, 10pm, 12-31-2007) for the records, then all the records till that point would be loaded to setup tables and all the records after that point of time will be moved to extraction queue or update tables. My question is, if this is true why would we ever need to lock the system during setup tables filling?
>
>     If you say the records after that particular time and date (10pm, 12-31-2007) will not be collected in extraction queue and update tables, why don't we do the following
>
>              a). say, I do full load with end date and time (10pm 12-31-2007)
>              b). Next, I do delta init with start date and time (10pm 12-31-2007) (this time I lock the postings)
>
>          If we do this way, we can actually reduce the down time of the system. Is my conclusion right?
>
>          If you say it's not practicable as some transactions' saving time differs from time stamp and some transactions' delta is even measured by pointer.......if this is the case we can use Delta offset. What do you say about this?
This is applicable to Generic Delta where you can set the Safety Interval (Upper Limit and lower Limit) for the extractor based on ALE Pointer, or Time Stamp or Calendar day.
If you excute a extractor with early delta init, during the setup table fill, the delta records will be directly written to the delta queue. The delta management handles these functionality.
[How to Create Generic Delta|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/84bf4d68-0601-0010-13b5-b062adbb3e33]
[SAP BI Generic Extraction Using a Function Module|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a0f46157-e1c4-2910-27aa-e3f4a9c8df33]
4
>
curious maven wrote:
How this scenario differs to early delta initialization?
If you do a Init without Early Delta init, then the user cannot post new documents and you have to either schedule in the weekend or request for a Source System downtime.
But if you use Early delta , then you don't need the source system down time and the user can post new records during the init, which will be written to the delta queue directly.
[How to Minimize Effects of Planned Downtime (NW7.0)|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/901c5703-f197-2910-e290-a2851d1bf3bb]
[How to Minimize Downtime for Delta Initialization (NW2004)|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5d51aa90-0201-0010-749e-d6b993c7a0d6]
Thanks
Chandran

Early Delta Init

Hi,
Can you please anybody solve my doubts
1.What is importance ' Early Delta Init '?
2. And which Data Sources are comes under this?
3. In which Scenario we will use this ?
Regards,
Ali

Hi,
Early Delta Initialization
With early delta initialization, you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the posting of data in the source system. The option of executing an early delta initialization is only available if the DataSource extractor called in the source system with this data request supports this.
Extractors that support early delta initialization are delivered with Plug-Ins as of Plug-In (-A) 2002.1.
You cannot run an initialization simulation together with an early delta initialization.
Hope this link may make you clear about Early Delta Initialization
http://help.sap.com/saphelp_nw04s/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/frameset.htm
Early delta Initialization
Hope this helps.
Regards
Raj

Delta Initialization vs Delta Update

We're having some issues with performance when loading our GL cube. What I would like to do is perform many delta initializations, each delta inititialization containing one month/period.
My confusion is in the fact that the last time I attempted this, when I subsequently went to run my delta UPDATE the same selection criteria was automatically inserted into my delta update.
So for example my INIT may look like this;
REQUEST1: Selection = 001.2005
REQUEST2: Selection = 002.2005
etc........etc...
REQUEST12: Selection = 012.2005
Next the UPDATE info package seems to inherit the same criteria... doesn't this mean it will not update anything beyond that criteria??
I'm just wondering if it is possible to do an incremental initialization and still be able to enable delta updates for future periods?
Thanks!

Hi Patrick,
The delta update will load the data as per the selections made in the Init run. A delta requested after several initializations, contains the sum of all the successful initial selections as a selection condition. This selection condition can then no longer be changed for the delta.
Take a look here for more info:
http://help.sap.com/saphelp_nw04/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/content.htm
Hope this helps...

Proc Chain - Delete Overlapping Requests fails with aggregates

BW Forum,
Our weekly/daily load process chain loads several full (not delta) transaction infopackages. Those infopackages are intended to replace prior full loads and are then rolled up into aggregates on the cubes.
The problem is the process chains fail to delete the overlapping requests. I manually have to remove the aggregates, remove the infopackages, then rebuild the aggregates. It seems that the delete overlapping request fails due to the aggregates or a missing index on the aggregates, but I'm not certain. The lengthy job log contains many references to the aggregate prior to it failing with the below messages.
11/06/2004 13:47:53 SQL-END: 11/06/2004 13:47:53 00:00:00                                                 DBMAN        99
11/06/2004 13:47:53     SQL-ERROR: 1,418 ORA-01418: specified index does not exist                        DBMAN        99
11/06/2004 13:47:59 ABAP/4 processor: RAISE_EXCEPTION                                                       00        671
11/06/2004 13:47:59 Job cancelled                                                                           00        518
The raise_exception is a short dump with Exception condition "OBJECT_NOT_FOUND" raised.
The termination occurred in the ABAP program "SAPLRRBA " in
"RRBA_NUMBER_GET_BW".
The main program was "RSPROCESS ".
I've looked for OSS notes. I've tried to find a process to delete aggregates prior to loading/deletion of overlapping requests. In the end, I've had to manually intervene each time we execute the process chain, so I've got to resolve the issue.
Do others have this problem? Are the aggregates supposed to be deleted prior to loading full packages which will require deletion of overlapping requests? I presume not since there doesn't seem to be a process for this. Am I missing something?
We're using BW 3.3 SP 15 on Oracle 9.2.0.3.
Thanks for your time and consideration!
Doug Maltby

Are the aggregates compressed after the rollup? If you compress the aggregate completely, the Request you are trying to delete is no longer identifiable once it is in the compressed E fact table (since it throws away the Request ID).
So you need to change the aggregate so that it the most recent Requests remain in the uncompressed the F fact table. Then the Request deletion should work.
I thought what was supposed to happen if the aggregate was fully compressed and then you wanted to delete a Request, the system would recognize that the Request was unavailable due to compression and that it would automatically refill the aggregate - but I'm not sure where I read that. Maybe it was a Note, maybe that doesn't happen in a Process Chain, just not sure.
The better solution when you regularly backout a Request is just not the fully compress the aggregate, letting it follow the compression of the base cube, which I'm assuming you have set to compress Requests older than XX days.

"The request failed with HTTP Status 400: Bad Request." when running reports

Hi,
I installed reporting services and the install went fine. The Reporting Services are located on a different server. I can see all the reports in SCCM but when I try to run them I get the "400" error with the following details:
System.Net.WebException
The request failed with HTTP status 400: Bad Request.
Stack Trace:
 at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
 at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
 at Microsoft.Reporting.WinForms.Internal.Soap.ReportingServices2005.Execution.ReportExecutionService.LoadReport2(String Report, String HistoryID)
 at Microsoft.Reporting.WinForms.Internal.Soap.ReportingServices2005.Execution.RSExecutionConnection.<>c__DisplayClass2.<LoadReport>b__0()
 at Microsoft.Reporting.WinForms.Internal.Soap.ReportingServices2005.Execution.RSExecutionConnection.ProxyMethodInvocation.Execute[TReturn](RSExecutionConnection connection, ProxyMethod`1 initialMethod, ProxyMethod`1 retryMethod)
 at Microsoft.Reporting.WinForms.Internal.Soap.ReportingServices2005.Execution.RSExecutionConnection.LoadReport(String Report, String HistoryID)
 at Microsoft.Reporting.WinForms.ServerReport.EnsureExecutionSession()
 at Microsoft.Reporting.WinForms.ServerReport.SetParameters(IEnumerable`1 parameters)
 at Microsoft.ConfigurationManagement.AdminConsole.SrsReporting.ReportViewerWindowsForms.SetParameterValues_DoWork(Object sender, DoWorkEventArgs e)
I can open the URL from the SCCM server but when I select a report I am unable to select any report options if available. If no options are availble the report just doesn't run, I don't get and error if I select "View Report" mutiple
times.
If I connect to the Reporting Services site on the computer where it is installed all the reports run fine.
One thing I have noticed is that when I try to change or add a role assignment for Reporting Services the edited account always reverts back to the default settings and the added Domain user is dropped.
Thanks

I reviewed the topic and found a couple of steps I missed the first time around. I had to "Configure Reports to Use Report Builder 3.0 and setting the "Log on Locally" permission.
I then uninstalled the role and reinstalled it. I am still getting the 400 error.
When I inspected the SmsAdminUI.log I noticed the Error on the last line 2151811598 (it repeats in the log). I couldn't find anything specific related to it. By reading a few "related" Internet posts I came accross a intial setup
blog that noted some WMI firewall execptions (Async-in, DCOM-in and WMI-in) as require so I checked and they were not allowed on the SCCM server so I allowed them and tested with the same result. I turned them off again.
Here is the tail end of the SmsAdminUI.log
[19, PID:2684][01/24/2013 16:08:29] :[ReportProxy] - User-specified default Reporting Point [INC-SQL42.deccoinc.net] could not be found, [] is now the default Reporting Point.
[4, PID:2684][01/24/2013 16:08:30] :[ReportProxy] - User-specified default Reporting Point [INC-SQL42.deccoinc.net] could not be found, [] is now the default Reporting Point.
[15, PID:2684][01/24/2013 16:08:30] :[ReportProxy] - User-specified default Reporting Point [INC-SQL42.deccoinc.net] could not be found, [] is now the default Reporting Point.
[1, PID:2684][01/24/2013 19:06:02] :System.Management.ManagementException\r\nNot found \r\n at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
 at System.Management.ManagementObject.Initialize(Boolean getObject)
 at System.Management.ManagementBaseObject.get_wbemObject()
 at System.Management.PropertyData.RefreshPropertyInfo()
 at System.Management.PropertyDataCollection.get_Item(String propertyName)
 at System.Management.ManagementBaseObject.GetPropertyValue(String propertyName)
 at System.Management.ManagementBaseObject.get_Item(String propertyName)
 at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.GetInstance(String objectPath)\r\nManagementException details:
instance of SMS_ExtendedStatus
Description = "Error retrieving object FileType=2";
ErrorCode = 2151811598;
File = "e:\\nts_sccm_release\\sms\\siteserver\\sdk_provider\\smsprov\\SspInterface.h";
Line = 1208;
Operation = "GetObject";
ParameterInfo = "SMS_SCI_SysResUse.FileType=2,ItemName=\"[\\\"Display=\\\\\\\\INC-SQL42.deccoinc.net\\\\\\\"]MSWNET:[\\\"SMS_SITE=INC\\\"]\\\\\\\\INC-SQL42.deccoinc.net\\\\,SMS SRS Reporting Point\",ItemType=\"System Resource Usage\",SiteCode=\"INC\"";
ProviderName = "ExtnProv";
StatusCode = 2147749890;
\r\n
[1, PID:2684][01/24/2013 23:39:14] :System.NullReferenceException\r\nObject reference not set to an instance of an object.\r\n at Microsoft.ConfigurationManagement.AdminConsole.SmsCustomDialog.get_LocaleIndependentIdentifier()
 at Microsoft.ConfigurationManagement.AdminConsole.ShowDialogTaskHandler.DoTask(NavigationModelNodeBase node, SccmTaskConfiguration sccmTask, PropertyDataUpdated dataUpdatedDelegate, Boolean readOnly)\r\n
[1, PID:5008][01/25/2013 20:48:00] :System.Management.ManagementException\r\nNot found \r\n at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
 at System.Management.ManagementObject.Initialize(Boolean getObject)
 at System.Management.ManagementBaseObject.get_wbemObject()
 at System.Management.PropertyData.RefreshPropertyInfo()
 at System.Management.PropertyDataCollection.get_Item(String propertyName)
 at System.Management.ManagementBaseObject.GetPropertyValue(String propertyName)
 at System.Management.ManagementBaseObject.get_Item(String propertyName)
 at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.GetInstance(String objectPath)\r\nManagementException details:
instance of SMS_ExtendedStatus
Description = "Error retrieving object FileType=2";
ErrorCode = 2151811598;
File = "e:\\nts_sccm_release\\sms\\siteserver\\sdk_provider\\smsprov\\SspInterface.h";
Line = 1208;
Operation = "GetObject";
ParameterInfo = "SMS_SCI_SysResUse.FileType=2,ItemName=\"[\\\"Display=\\\\\\\\INC-SQL42.deccoinc.net\\\\\\\"]MSWNET:[\\\"SMS_SITE=INC\\\"]\\\\\\\\INC-SQL42.deccoinc.net\\\\,SMS SRS Reporting Point\",ItemType=\"System Resource Usage\",SiteCode=\"INC\"";
ProviderName = "ExtnProv";
StatusCode = 2147749890;
\r\n

The request failed with HTTP status 401: Unauthorized Invoke Webservice

I want Adding a Web reference dynamically at Runtime follow
SecurityPermissionAttribute(SecurityAction.Demand, Unrestricted = true)]
internal static object CallWebService(string webServiceAsmxUrl, string serviceName, string methodName, object[] args)
System.Net.
WebClient client = new System.Net.WebClient();
client.Credentials =
new NetworkCredential("username", "pass");
// Connect To the web service
System.IO.
Stream stream = client.OpenRead(webServiceAsmxUrl + "?wsdl");
// Now read the WSDL file describing a service.
ServiceDescription description = ServiceDescription.Read(stream);
///// LOAD THE DOM /////////
// Initialize a service description importer.
ServiceDescriptionImporter importer = new ServiceDescriptionImporter();
importer.ProtocolName =
"Soap12"; // Use SOAP 1.2.
importer.AddServiceDescription(description,
null, null);
// Generate a proxy client.
importer.Style =
ServiceDescriptionImportStyle.Client;
// Generate properties to represent primitive values.
importer.CodeGenerationOptions = System.Xml.Serialization.
CodeGenerationOptions.GenerateProperties;
// Initialize a Code-DOM tree into which we will import the service.
CodeNamespace nmspace = new CodeNamespace();
CodeCompileUnit unit1 = new CodeCompileUnit();
unit1.Namespaces.Add(nmspace);
// Import the service into the Code-DOM tree. This creates proxy code that uses the service.
ServiceDescriptionImportWarnings warning = importer.Import(nmspace, unit1);
if (warning == 0) // If zero then we are good to go
// Generate the proxy code
CodeDomProvider provider1 = CodeDomProvider.CreateProvider("CSharp");
// Compile the assembly proxy with the appropriate references
string[] assemblyReferences = new string[5] { "System.dll", "System.Web.Services.dll", "System.Web.dll", "System.Xml.dll", "System.Data.dll" };
CompilerParameters parms = new CompilerParameters(assemblyReferences);
CompilerResults results = provider1.CompileAssemblyFromDom(parms, unit1);
// Check For Errors
if (results.Errors.Count > 0)
foreach (CompilerError oops in results.Errors)
System.Diagnostics.
Debug.WriteLine("========Compiler error============");
System.Diagnostics.
Debug.WriteLine(oops.ErrorText);
throw new System.Exception("Compile Error Occured calling webservice. Check Debug ouput window.");
// Finally, Invoke the web service method
object wsvcClass = results.CompiledAssembly.CreateInstance(serviceName);
MethodInfo mi = wsvcClass.GetType().GetMethod(methodName);
return mi.Invoke(wsvcClass, args);
else
return null;
When i call CallWebService method , it is error
The request failed with HTTP status 401: Unauthorized.
Exception Details: System.Net.WebException: The request failed with HTTP status 401: Unauthorized.
Source Error:
Line 1880: MethodInfo mi = wsvcClass.GetType().GetMethod(methodName);
Line 1881:
Line 1882: return mi.Invoke(wsvcClass, args);
Help me solve this problem.
Thanhks

Thank advance
I tried it, but it till error
Stack Trace:
[WebException: The request failed with HTTP status 401: Unauthorized.]
System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) +431201
System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) +204
HSCVWS.HelloWorld() +31
[TargetInvocationException: Exception has been thrown by the target of an invocation.]
System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) +0
System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) +71
System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) +350
System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) +29
System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters) +19
WsProxy.CallWebService(String webServiceAsmxUrl, String serviceName, String methodName, Object[] args) in d:\ViDu01\ttt.aspx.cs:1882
ttt.Page_Load(Object sender, EventArgs e) in d:\ViDu01\ttt.aspx.cs:27
System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +14
System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +35
System.Web.UI.Control.OnLoad(EventArgs e) +99
System.Web.UI.Control.LoadRecursive() +50
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +627
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2009-06-09 02:43:10
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2009-06-09 02:43:10 192.168.2.46 GET /_vti_bin/testwebservice.asmx wsdl 80 - 192.168.x.xx - 200 0 0
2009-06-09 02:43:13 192.168.2.46 POST /_vti_bin/testwebservice.asmx - 80 - 192.168.x.xx Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.3053) 401 5 0
2009-06-09 02:43:16 192.168.2.46 GET /_vti_bin/testwebservice.asmx wsdl 80 - 192.168.x.xx - 200 0 0
2009-06-09 02:43:17 192.168.2.46 POST /_vti_bin/testwebservice.asmx - 80 - 192.168.x.xx Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.3053) 401 5 0
2009-06-09 02:44:42 192.168.2.46 POST /_vti_bin/testwebservice.asmx - 80 servername\username 192.168.x.xx Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.3053) 200 0 0

When exactly source system recognizes the last delta is succesfull/failed.

When exactly does the source system recognizes the last delta is successful/failed?
Case -1: In logistic applications..
             What if I changed quality status to red for a successfully completed delta, and then requested new delta?
Case -2 : In Financial applications..
              When exactly BWOM2_TIMEST fields updated. I mean BW acknowledges to the delta load immediately saying it is successful or fail, or at the time when we request the next delta?
              What if I changed quality status to red for a successfully completed delta, and then requested new delta? It executes repeat or returns 0 records.

Hi,
Here's the explanation:
Scenario 1 -Logistics Delta
Sinc logistics delta comes from Delta Queue (RSA7) and IP takes daa from Delta queue so betwen RSA7 and BW, IDocs are transferred which sends messages for successful completon of extraction. As soon as extraction is over and a particular IDoc is sent to BW the BW marks the delta s successful. This happenes exactly when job is Source system completes Now if you make a successful delta as red then the IP identifies that last delta was not successful and requestes a repeat of last delta which again goes to RSA7 and picks the last delta and also the new deltawhich has come in RSA7. Note: RSA7 stores both new delta records and one last successful delta records(for delta repeat)
Scenario 2 - FI Delta
Sinc FI deltas are based on timestamp mechanism there are 2 possibilities:
a) The extraction fails while picking records from R/3 table (G/L, Ap and AR tables). In this case the timestamp isnot registered in BWOM2_TIMEST table and arepeat will work fine.
b) The load fails during procssing in BW (e.g update rules processing) and the job has completed in R/3 and has set the timestamp in table BWOM_TIMEST. In this case we will have to reetthe tmestamp and run the delta again.

BW early delta initialization request failed

Similar Messages

Maybe you are looking for