Agentry Delta Mechanism - Detecting changes in nested objects?

Hi all,
I have some experience with the Agentry Delta mechanism directly on a SQL backend (Update / Exchange Tables, Triggers, etc.). Now I am trying to find the right documentation, examples and stuff for that mechanism in the "Work Manager for SAP 6.0".
Maybe, someone could outline a solution to the following "gap" in the Standard Work Managers exchange mechanism?
A notifications in the "Work Manager" is updated, when the description of the notification has been changed in SAP.
However, a notification is not updated, when the description of the functional locations of the notification has been changed in SAP. Now, the question is, how to extend the exchange mechanism to listen to the functional locations description?
Thanks in advance for any hints you might have.
Regards, Daniel

Note: I reposted this question in its own discussion. Please do reply there if you can contribute to this topic. Thank you!
Hi,
its me again. I did some reading and I found something called "Exchange Object Linkage Settings" that sounds like it should be used for the use case above. The problem is, that it does not seem to work as I would expect.
Here is some description from the smp_agentry_sap_framework.pdf, page 78:
Exchange Object - Linkage Settings The Linkage Settings tab allows the exchange objects that are linked together to communicate with each other. The communication is one-directional, with the exchange object sending information to the object(s) listed in the Linked Exchange Objects List. When there is a value change to the exchange object, that value change information is passed on to the linked exchange objects. The linked exchange objects then go through additional processes related to the value change.
In the Config Panel, one can see that in the Standard Work Manager, there is a linkage between Functional Location and Workorder:
(Note that I started this discussion with an example on Notifications and Functional Locations. This is still where I want to go, but I wanted to stay within the Standard Workmanager Setup to make the - hopefully - ongoing discussion easier to follow.)
According to the above description, I would expect that, when changing the Functional Locations description, that information is passed to all Workorders with that Functional Location.
BUT HOW? It is not entirely clear to me how and what information is passed where. I would expect, that in the end, all related entries in the workorder exchange table will be updated with a new time stamp. (How else could the client get the information that the workorder is to be updated?)
This is not what I can see! When changing the Functional Locations description in SAP, I see that the Functional Locations exchange table entry is updated, but the corresponding Work Orders exchange table entry is not changed.
Does anybody have an idea how this feature is supposed to work? Maybe, there are some configuration steps necessary? Any input on the would be highly appreciated.
Regards, Daniel

Similar Messages

Detecting changes in an object

I have a relatively simple 3 tier application. Swing client, business logic with JDBC calls to fetch and save data on the server side. My data layer is simply comprised of JDBC calls which I use to populate JavaBeans, which are then returned to the client.
I want an easy way to be able to tell if the object has been changed, regardless of where it is at (client, business logic, etc). If I have a Person object, I want to be able to call person.hasDataChanged(), or something like that.
At first, I simply kept a dirty flag on the object. I then set this dirty flag to TRUE whenever one of the SET methods is called with data which differs from the current value. This works, and is fairly simple. By only setting the flag for set calls that use different data, I can map data to and from window objects without flipping the flag when I don't want to. The only problem with this is that it's possible to change the data from A to B, then set it back to A. At this point my object hasn't really chagned, but the dirty flag says otherwise.
So I thought of storing a copy of the old object within the object itself, but that seems like I'm passing around more data than I need to. Every object is twice as big as it needs to be.
I then tried to create a hash value when the object is retrieved from the database based upon the combined attributes of the object. The hasDataChanged() method creates a new hash value based upon the current data, compares with the old hash value, and returns the results. This doesn't work though, as there is no guarantee that hash values will be unique. It's possible to have data change and not have it be picked up.
So I now have a long string which I create when the object is first created. It is simply a concatonation of each object attributed. The hasDataChanged() method creates a new value string, compares to the old value string, and returns to the result.
Am I missing an obvious solution? Should I stick with the original approach of flipping a flag on the setter, even though it may be incorrect in instances where data is changed multiple times?
Thanks.

In my, opinion, you may be overcomplicating the issue
a little. If an attribute changes and is then changed
back, does it really matter if the object is no longer
differnt from the original. A simple 'dirty' flag is
usually goos enough for most systems.I suppose the worst that could happen is that I update a record in the database with the exact same data. Not the end of the wolrd I suppose. Still, if there was an easy wa to get it right, I would like to do so.
Having said that, If you absolutely must know
if it is different from the persistent version of the
object, you could place your persited data into a
contained object, something like a memento. Then ,
when a change is made, a comparison is made between
the current state and the stored memento. This would
have a higher memory and processing overhead, though.Yeah, I figured that was likely going to be the case. The downside is that the object is heavier; although it may be that it really doesn't matter.
Actually, all of these would require me to figure out when to take the snapshot of the object. They are JavaBeans, so I create them with an empty constructor, and then call setter methods to set the values on the object from a database result set. So I need a way to tel the object, "Ok, any data change after this means you've been altered". I hadn't thought that through all the way.
-Dave

[svn:bz-3.x] 20876: Change default max object nest level to 512.

Revision: 20876
Revision: 20876
Author:   [email protected]
Date:     2011-03-16 09:02:36 -0700 (Wed, 16 Mar 2011)
Log Message:
Change default max object nest level to 512. A max object nest level of 512 should be more than enough for most applications which probably will not be sending deeply nested object graphs over the wire. For applications that are sending deeply nested object graphs over the wire and that bump up against this limit, the limit can be increased but you should also do testing to make sure that serializing/deserializing these deeply nested object graphs doesn't cause stack overflow errors.
Add documentation for the max object nest level setting.
Add documentation for the max collection nest level setting.
Checkintests: passed
Modified Paths:
    blazeds/branches/3.x/modules/core/src/java/flex/messaging/endpoints/AbstractEndpoint.java
    blazeds/branches/3.x/resources/config/services-config.xml

Remember that Arch Arm is a different distribution, but we try to bend the rules and provide limited support for them. This may or may not be unique to Arch Arm, so you might try asking on their forums as well.

[svn:bz-4.0.0_fixes] 20874: Change default max object nest level to 512.

Revision: 20874
Revision: 20874
Author:   [email protected]
Date:     2011-03-16 06:55:37 -0700 (Wed, 16 Mar 2011)
Log Message:
Change default max object nest level to 512. A max object nest level of 512 should be more than enough for most applications which probably will not be sending deeply nested object graphs over the wire. For applications that are sending deeply nested object graphs over the wire and that bump up against this limit, the limit can be increased but you should also do testing to make sure that serializing/deserializing these deeply nested object graphs doesn't cause stack overflow errors.
Add documentation for the max object nest level setting.
Add documentation for the max collection nest level setting.
Remove max-string-length-bytes setting from the example services-config.xml as this setting doesn't exist.
Checkintests: passed
Modified Paths:
    blazeds/branches/4.0.0_fixes/modules/core/src/flex/messaging/endpoints/AbstractEndpoint.j ava
    blazeds/branches/4.0.0_fixes/resources/config/services-config.xml

Remember that Arch Arm is a different distribution, but we try to bend the rules and provide limited support for them. This may or may not be unique to Arch Arm, so you might try asking on their forums as well.

How to make added custom field Delta mechanism work for LO Cookpit?

We appended a new custome field into extraction structure of the LO Cookpit datasource 2LIS_02_ITM through RSA6. And then run CMOD to write the exit code to populate the value and it works fine. But after we read Roberto's Weblog:
/people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it , find the enhancement we did can't make the Delta mechanism works if only this new field gets changed in a record, and the change cannot be reflected on BW.
In order to make the Delta mechansim works, one option is to append the custom field into one of the LIS Communication Structure MCEKKO of 2LIS_02_ITM extraction structure and then write the enhancement code to this LIS Communication Structure. In this way, the custom field can be treated like standard field that whenever it gets changed, the Delta mechanism or the user exit will be triggered. The enhancement for this LIS Communication Struture is LEINS001.
Now we've got two problems when doing the above enhancements of the LIS Communication structure:
1. Maintain extraction structure problem in LBWE:
We added a custom field, e.g., called ZZZ in LIS Communication structure MCEKKO (Purchasing Document Header) by creating a new custom append structure and add the field ZZZ into it, then activate the new append structure, but get warning msg like "Field name DUMMY is reserved (Do not use structure as include in DB table)".
We do find a field called DUMMY in the structure MCEKKO. How to get rid of the warning msg and successfully activate the new custom append structure with the new field ZZZ?
You could say that we can ignore the warning msg, but why the new custom field appended can not be seen from the right side pool of the Maintain Extract Structure in LBWE? We need to make the new custom field shows up in the right side pool and then drag it over to the left side frame and to activate the extraction structure to change it. But now it doesn't show up in the right frame pool!
2. Refer to Sanyam's weblog
/people/sanyam.kapur/blog/2005/04/30/custom-fields-and-bw-extractors-making-a-mixed-marriage-work-part-ii, there is a sample code inside this article which tells us how the sample code looks like to write this LIS Communicaton structure enhancement to make the Delta mechanism works, below is the code we modified to suit our needs, but don't know if it would work?
DATA: i_t_ekko LIKE ekko   OCCURS 1 WITH HEADER LINE.
DATA: ebeln LIKE ekpo-ebeln,
      it_ekko TYPE TABLE OF ekko WITH HEADER LINE,
      old_val(50) TYPE c. "For storing the value from the Field Symbol
FIELD-SYMBOLS <fs> TYPE ANY TABLE.
CASE zeitp.
WHEN 'MA'.                            "When creating a purchase order
    MOVE '(SAPLEINS)T_EKKO[]' TO old_val.
    ASSIGN (old_val) TO <fs>.
    i_t_ekko[] = <fs>.
    LOOP AT xmcekko.
      ebeln = xmcekko-ebeln.
      IF xmcekko-supkz = '1'.            "Old Value ?
        SELECT SINGLE * FROM ekko INTO it_ekko WHERE ebeln = ebeln.
        xmcekko-ZZZ = it_ekko-ZZZ.
      ELSE.                              "New Value ?
        READ TABLE i_t_ekko WITH KEY ebeln = ebeln.
        xmcekko-ZZZ = i_t_ekko-ZZZ.
      ENDIF.
      MODIFY xmcekko.
    ENDLOOP.
EndCase.
Share your ideas and we will give you reward points!

Hello Kevin
We have exactly the same problem. Did you solve it? If you did, could you please tell us how you did it? We neither see our field in LBWE. Our field is a Z field from a Z table.
I hope you could help us. We just have this issue to finish our project.
Thanks a lot in advanced

Detect changes in an instance

Hello,
how can I detect changes in an instantiated object? I could serialize the object and write it into a file. After some minutes I could write it a second time into a file. Now I could compare the two files. But I thing this is not the best way for doing this, isnt't it.
Any suggestions?
Thanks

it can be of any help, here's how I implement object changes:
/** Interface for object instances comparison */
interface ContentComparable {
   /** Returns a string describing the object instance for comparison */
   public String getCompareString();
/** Custom class sample */
public class CustomClass implements ContentComparable {
   private String    customField1;
   private int       customField2;
   /** Constructor */
   private CustomClass(String field1, int field2) {
      this.customField1 = field1;
      this.customField2 = field2;
   //------------------------------------------------------------ ContentComparable ---
   /** Returns a string describing the object instance for comparison */
   public String getCompareString() {
      String content = this.getClass().getName() + "["
                       + "customField1='" + this.customField1 + "', "
                       + "customField2=" + this.customField2 + "]";
       return content;
   /** Returns TRUE if the object is equal to an other object
    * @param   otherobj the other object
    * @return TRUE or FALSE
    * @see #getCompareString()
   public boolean equals(Object otherobj) {
      if (otherobj instanceof CustomClass) {
         CustomClass classobj = (CustomClass)otherobj;
         return this.getCompareString().equals(classobj.getCompareString());
      return false;
}With that, you just have to keep a copy of the getCompareString() of the object before any changes are made.
When you want to test changes, call this method:
   // private member to hold copy of unchanged object string
   private String oldObjectValue;
   // Returns TRUE if object has changed
   private boolean testDataChanged() {
      if (oldObjectValue == null) oldObjectValue = object.getCompareString();
      String newObjectValue = object.getCompareString();
      return !oldObjectValue.equals(newObjectValue);
   //...Hope this helped,
Regards.

Trigger Material Delta Load by changing characteristic in R/3

Hello,
We added some functionallity to our R/3 and CRM system in order to map the R/3 characteristic data to CRM attributes (which are added to the product master). During the initial download of materials this works fine.
The delta download is triggered when I change something in the Basic Data or the Sales Org. data in transaction MM02 on the R/3 site, but NOT when I change something in the Classification tab (which holds the characteristics).
Does anyone know how to trigger the Material Delta Load when changes in the Classification tab are made?
Thanks,
Jeroen

Hi Pat,
Use object 'DNL_CUST_SALES' to download Customer Group from R/3 to CRM.
Use R3AS4 transaction to execute the same.
Best Regards,
Pratik Patel
<b>Reward with Points!</b>

COPA Delta Mechanism

Hi All,
Can any one explain about Delta Mechanism in COPA ie.,
How delta works in COPA,
From where the delta record are picked,
When the Delta Queue is filled,
what is Safety Delta,
What is Relignment and when we go for that, etc.....
Thanks in Advance,
Regards
Ramakrishna Kamurthy

Hi Ramakrishana,
Up to and including Plug-In Release PI2003.1, a DataSource is only
defined in the current client of the R/3 System. This means that a
DataSource can only be extracted from this client. The DataSource has a
timestamp for the delta method, and this timestamp is only valid for th
current client. This timestamp is managed by Profitability Analysis.
With Plug-In Release PI2004.1 (Release 4.0 and higher), timestamp
management was converted to a new method, called generic delta. This
method works in connection with an SAP BW system with Release 2.0 and
higher. With this method, timestamp management is no longer performed b
Profitability Analysis, but instead by the Service API (interface on th
R/3 side between Profitability Analysis and SAP BW). Exclusively in
Release 3.1I, Profitability Analysis continues to support timestamp
management.
Compared to timestamp management in Profitability Analysis, the generic
delta allows for several enhancements:
o   You can apply the delta method simultaneously using the same
     DataSource from more than one R/3 System client because a separate
     timestamp is saved for each logical system.
o   You can apply the delta method for the same R/3 System client
     simultaneously using the same DataSource from several SAP BW
     systems.
o   You can perform several initializations of the delta method with
     different selections using the same DataSource from a given SAP BW
     system for the same R/3 System client.
o   The DataSource commands the Delta Init Simulation mode. With
     timestamp management in Profitability Analysis, this mode had to be
      implemented using the Simulate Delta Method Initialization function
      (see SAP Note 408366).
For more information on the generic delta, see Delta Transfer, whereby
the steps of the Specify Generic Delta for a DataSource section are
performed automatically for Profitability Analysis when a DataSource is
created. For this, the field determining the delta is taken as the
timestamp for Profitability Analysis (TIMESTMP), and the timestamp is
stored for summarization levels and line item tables. However, in
contrast to generic DataSources, the TIMESTMP field is not generated in
the extraction structure because this is not necessary for DataSources
in Profitability Analysis. As with timestamp management in Profitabilit
Analysis, an upper limit of 30 minutes is set as the safety interval.
You find the timestamp of a DataSource for the delta method in the
current logical system either in the Header Information for the
DataSource using the IMG activity Display Detailed Information on
DataSource or using the IMG activity Check Delta Queue in the Extractor
IMG. The timestamp is shown here when you choose the selection button i
the Status column for the combination of DataSource and SAP BW system.
DataSources created after implementing PI2004.1 automatically apply the
new method. DataSources that were created in Plug-In releases prior to
PI2004.1 still continue to use timestamp management in Profitability
Analysis but can be converted to the generic delta. For this, an
additional selection option Convert to Generic Delta appears in the
selection screen of the IMG activity Create Transaction Data DataSource
when a DataSource with timestamp management in Profitability Analysis i
entered. Conversion from the generic delta to timestamp management in
Profitability Analysis is not supported.
Conversion is only possible for DataSources that are defined in the
current client of the R/3 system and for which the delta method has
already been successfully initialized or for which a delta update has
successfully been performed. This is the case once the DataSource has
the replication status Update successful. Furthermore, no realignments
should have been performed since the last delta update.
For the conversion, the timestamp for the current R/3 System client is
transferred from Profitability Analysis into the timestamp of the
generic delta. In this way, the transition is seamless, enabling you to
continue to perform delta updates after the conversion. If delta updates
are to be performed from different R/3 System clients for this
DataSource, you first need to initialize the delta method for these
clients.
The conversion must be performed separately in each R/3 System because
the timestamp information is always dependent on the current R/3 System
and is reset during the transport. If, however, a converted DataSource
is inadvertently transported into a system in which it has not yet been
converted, delta extraction will no longer work in the target system
because the timestamp information is deleted during the import into the
target system and is not converted to the timestamp information of the
generic delta. If in this instance no new delta initialization is going
to be performed in the target system for the DataSource, you can execute
program ZZUPD_ROOSGENDLM_FROM_TKEBWTS from SAP Note 776151 for the
DataSource. This program reconstructs the current time stamp information
from the information for the data packages transported thus far and
enters this time stamp information into the time stamp information for
the generic delta. Once this program has been applied, delta extraction
should work again. Normally, however, you should ensure during the
transport that the DataSource uses the same logic in the source system
and the target system.
After the conversion, the DataSource must be replicated again from the
SAP BW system.
A successful conversion is recorded in the notes on the DataSource,
which you can view in the IMG activity Display Detailed Information on
DataSource.
Since the generic delta does not offer any other log functions apart
from the timestamp information (status: Plug-In Release PI2004.1),
Profitability Analysis still logs the delta initialization requests or
delta requests. However, the information logged, in particular the
timestamps, only has a statistical character because the actual
timestamp management occurs in the generic delta. Since the delta method can be performed simultaneously for the same R/3 System client using the
generic delta from several SAP BW systems, the information logged is
stored for each logical system (in R/3) and SAP BW system. When a delta
initialization is simulated, only the timestamp of the generic delta is
set; Profitability Analysis is not called. Consequently, no information
can be logged in this case. Messages concerning a DataSource are only
saved for each logical system (in R/3). You can use the IMG activity
Display Detailed Information on DataSource to view the information
logged.
Another enhancement from Plug-In Release PI2004.1 means that you can no
longer exclusively perform full updates for DataSources of the Extractor
Checker of the Service API that have recently been created or converted
to the generic delta. The following update modes are possible:
o   F - Full update: Transfer of all requested data
o   D - Delta: Transfer of the delta since the last request
o   R - Repeat transfer of a data package
o   C - Initialization of the delta transfer
o   S - Simulation of the initialization of the delta transfer
In the case of all update modes other than F, you have to specify an SAP
BW system as the target system so that the corresponding timestamp
and/or selection information for reading the data is found. The Read
only parameter is set automatically and indicates that no timestamp
information is changed and that Profitability Analysis does not log the
request.
Update mode I (transfer of an opening balance for non-cumulative values)
is not supported by Profitability Analysis.
Assign Points if useful
Regards
Venkata Devaraj

Delta Mechanism for LO Extraction.... urgent plz

hi experts,
Could you plz.. give me the details below for LO EXTRACTION DELTA MECHANISM.
for the first time load i have done initialize with data transfer. what should i do if i want to extract the new data(Changed Records) from r/3. what are all the settings i need to give. i am using BI7.
plz provide me the documentation for LO EXTRACTION DELTA MECHANISM.
regards
vadlamudi

Hi,
After initialization you need to check the deltas in RSA7 after the load.
For further explanation check these blogs by Roberto Negro:
Episode one:
/people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
Episode two:
LOGISTIC COCKPIT DELTA MECHANISM - Episode two: V3 Update, when some problems can occur...
Episode three:
LOGISTIC COCKPIT DELTA MECHANISM - Episode three: the new update methods
Also check
Gist of LO Cockpit Delta
Assign points if this helps........
Rgs,
I.R.K

Delta mechanism for 0fi_gl_14

Hi,
We are using 0fi_gl_14 DS for extracting leading ledger's line item data.
But when I checked table BWOM2_TIMEST, there is no entry for the above data source.
Could someone help me understand delta mechanism for 0fi_gl_14?
Is it not similar to 0fi_gl_4 delta?
What is the difference between 0fi_gl_4 and 0fi_gl_14?
Regards,
Shravani

Hi,
Most of the extractors (specially one in question 0FI_GL_14) in FI related extractors work on pull mechanism via Extraction method: F1 (function module (complete interface))
Extractor: FAGL_GET_SI_DATA
1. 0FI_GL_14 extractor, considers all data from the tables FAGLFLEXA (or similar customer tables), BKPF, BSEG, and BSEG_ADD. we use this extractor if New GL configuration done in ECC or otherwise 0FI_GL_4 still holds good.
2.Coming to Delta are picked from BWFI_AEDAT table where all the changed documents/new are maintained as part of changed status.
Hope i have addressed your question!
Regds,
Karunakar P

0FC_BP_ITEMS: ERP customizing and delta mechanism

Hi BI fans
I have two questions:
1.) The following link describes how to make the settings for delta enabling of datasource 0FC_BP_ITEMS:
http://help.sap.com/saphelp_nw70/helpdata/en/27/42073e774a4329b6dd6bab21eef613/frameset.htm
Prerequisites-
"...If you want to use the delta method, you first have to activate it in the Implementation Guide for Contract Accounts Receivable and Payable -> Integration Business Intelligence -> Maintain Central Settings in the clients of the OLTP system..."
But I cannot find the setting for "Maintain Centrall Settings" in the implementation guide!
Any idea from your side?
What I see are entries for:
Define Fields for the Extraction of Items
Define Grid for Grouping of Items
2.) What is the exact delta logic of this extractor (working through function module)?
Which fields are relevant for the delta logic?
Thanks
BEOplanet

Hi Andrea
First of all I activated the whole content (datasource, BW content, etc.).
Regarding the pseudo-delta on CPUDT I have designed a BEx variable on a DATS 8 time characteristic, e.g. 0NETDUEDATE. It is a BEx variable feeded by a customer exit, you will find a sample coding below. Furthermore an interval variable, mandatory input.
Screen for BEx variable properties:
Assign this BEx variable into your infopackage for intended use of pseudo-deltas, type OLAP-variable:
The sample coding below gives you an idea about our pseudo-delta mechanism, from 1st. of last month until sy-datum.
Data wa1 like line of e_t_range.
data d1 type d.
data fdate type d.
data fyear type d.
data ldate type d.
data fmonth type d.
case i_vnam.
when 'ZL2MTDY'. "BEx variable on 0NETDUEDATE or any other DATS 8 time characteristic
d1 = sy-datum.
fdate = d1 - 31.
fdate+6(2) = '01'.
ldate = sy-datum.
wa1-opt = 'BT'.
wa1-sign = 'I'.
wa1-low = fdate.
wa1-high = ldate.
append wa1 to e_t_range.
ENDCASE.

Error while changing the Resource Object Status

Hi,
I am trying to change the resource object status from Waiting to Provisioned for a self service task. Before approval I see the Resource Object Status as " Ticket Sent To REMEDY" on the administrator's web console and at the Requestor's web console I get the following error message-
???en_US.global.viewProfileForm.Lookup.Ticket-Sent-to-REMEDY???
But after approval, based on the completion the task, the process on both the consoles is set to provisioned. That is what I want to display but the problem comes when the requestors sees the error status message on its console before approval.
Can any body tell me the reason of the above error and how to resolve it?
Thanks in advance

do you have any custom written event handlers getting triggered off after request submission or during approval?
It might also be due to either a browser issue or you might have missed any entry in the xladmin properties file for a custom label/error message etc.

Do you know how to change the Text Object for Billing Document?

Hi,
If you execute Transaction VOTX or VOTXn it will take you to Text Determination. The Billing Doc & Sales Document both has the VBBK as Text Object for me and is it like that for all.
I need to change the Text Object to VBRK for Billing Doc, which is the ideal because I am using the Function Module READ_TEXT to retrieve text. This work perfectly for Sales Document which has VBBK as Text Object, but does not work for Billing Doc where it through as error message saying Text 0020000021 ID 0002 language EN not found.
Thank You
Kishan

Hi kishan,
For updating these text you can use FM 'SAVE_TEXT'.
As for your problem, to get the parameter you need, go to the billing document, go to the text, and display it in plain page mode.
Then you do 'GO TO' -> 'HEADER', and a pop-up window open with the parameters you need Obect type, ID, Name, ...
Regards,
Erwan.

Data not updated in business entity after change in architectural object

Hi,
A business entity was created from Architectural Object.
When we modify the address in the architectural object, the data is not updated in the business entity.
Is there any solution that make an automatic update for the address in business entity after a change in architectural object ?
Thx for your help.
Regards
Saad

Hi,
I have created new infopackage and ran. Now the following message I have got on the monitor.
"Data not received in PSA Table
Diagnosis
Data has not been updated in PSA Table . The request is probably still running or there was a short dump.
Procedure
In the short dump overview in BW, look for the short dump that belongs to your data request. Make sure the correct date and time are specified in the selection screen.
You can use the wizard to get to the short dump list, or follow the menu path "Environment -> Short dump -> In Data Warehouse".
Removing errors
Follow the instructions in the short dump."
Any more thoughts?
Thanks,
Rao.

Can we show the nested objects in Powershell?

I am adding a .NET type to Powershell session using Add-Type and then creating object of that type using New-Object. This is done as follows:
Add-Type -AssemblyName OuterObj
$a = New-Object OuterObj
Object of type OuterObj is successfully created. Now .NET type $a has a field named innerObj which is object of another .NET type innerObject. So I add "innerObject" .NET type and create an instance using New-Object.
Add-Type -AssemblyName innerObject
$b = New-Object innerObject
Object of type innerObject is also successfully created. Now I do as follows:
$a.innerObj = $b
Now when I print $a, it shows something like this:
innerObj : innerObject
Thus it does not display the contents of innerObject by default. When I go and explore, innerObj has the fields. I know Powershell does not show the nested objects by default but instead just shows their types, but is there a way I can specify that what
level of nesting of objects powershell should show by default? Is there something to specify to show 1 or 2 levels of nested objects?
Any help would be highly appreciated.

The simplest approach, if you're writing these C# classes yourself, is probably to override the class's ToString method. That way it will just display that way by default in PowerShell, without any extra effort on the scripter's part.
If that's not an option, then you can write PowerShell code to accomplish something similar. Here are examples of both:
# C# ToString version:
Add-Type -TypeDefinition @'
public class innerObject
public string Property1;
public string Property2;
public override string ToString()
return string.Format("Property1: {0}, Property2: {1}", Property1, Property2);
public class OuterObj
public innerObject innerObj;
$a = New-Object OuterObj
$b = New-Object innerObject -Property @{ Property1 = 'First Property'; Property2 = 'Second Property' }
$a.innerObj = $b
$a | Format-List
# PowerShell version using constructed property values with
# Format-List.
Add-Type -TypeDefinition @'
public class innerObject
public string Property1;
public string Property2;
public class OuterObj
public innerObject innerObj;
$a = New-Object OuterObj
$b = New-Object innerObject -Property @{ Property1 = 'First Property'; Property2 = 'Second Property' }
$a.innerObj = $b
$a | Format-List -Property @{ Label = 'innerObj'; Expression = { "Property1: $($_.innerObj.Property1), Property2: $($_.innerObj.Property2)" } }

Agentry Delta Mechanism - Detecting changes in nested objects?

Similar Messages

Maybe you are looking for