FAQ: BW delta queue (RSA7): Questions and answers

Questions and answers.Question 1:What does the number in the 'Total' olumn in Transa tion RSA7 mean!Answer:The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repeating a delta request) and the LUWs for the ne t delta request. !n LUW only disappears from the "#!$ display when it has been transferred to the %W #ystem and a new delta request has been received from the %W #ystem.Question ":What is an #$W in the delta queue!Answer:!n LUW from the point of view of the delta queue can be an individual document& a group of documents from a collective run or a whole data pac'et from an application e tractor.Question %:Wh& does the number in the 'Total' olumn' in the o(er(iew s reen o) Transa tion RSA7' di))er )rom the number o) data re ords that are dis*la&ed when &ou all u* the detail (iew!Answer:The number on the overview screen corresponds to the total number of LUWs (see also question () that were written to the q")* queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. %oth the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. This means that only the records that are ready for the ne t delta request are displayed on the detail screen. The detail screen of Transaction "#!$ does not ta'e into account a possibly e isting customer e it.Question +:Wh& does Transa tion RSA7 still dis*la& #$Ws on the o(er(iew s reen a)ter su ess)ul delta loadin,!Answer:+nly when a new delta has been requested does the source system learn that the previous delta was successfully loaded into the %W #ystem. The LUWs of the previous delta may then be confirmed (and also deleted). ,n the meantime& the LUWs must be 'ept for a possible delta request repetition. ,n particular& the number on the overview screen does not change if the first delta is loaded into the %W #ystem.Question -:Wh& are sele tions not ta.en into a ount when the delta queue is )illed!Answer:)iltering according to selections ta'es place when the system reads from the delta queue. This is necessary for performance reasons.Question /:Wh& is there a 0ataSour e with '1' re ords in RSA7 i) delta e2ists and has been loaded su ess)ull&!Answer:,t is most li'ely that this is a -ata#ource that does not send delta data to the %W #ystem via the delta queue but directly via the e tractor . .ou can display the current delta data for these -ata#ources using T! "#!/ (update mode 0'-')Question 7:0o the entries in Table R340356R7S ha(e an im*a t on the *er)orman e o) the loadin, *ro edure )rom the delta queue!Answer:The impact is limited. ,f performance problems are related to the loading process from the delta queue& then refer to the application1specific notes (for e ample in the *+12! area& in the logistics coc'pit area& and so on).*aution3 !s of 2lug,n 4555.4 patch /& the entries

in Table "+,-+*2"6# are as effective for the delta queue as for a full update. 7ote& however& that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the delta queue& the actual pac'age si8e may differ considerably from the 6!9#,:; and 6!9L,7;# parameters.Question 8:Wh& does it ta.e so lon, to dis*la& the data in the delta queue ()or e2am*le a**ro2imatel& " hours)!Answer:With 2lug,n 455(.( the display was changed3 you are now able to define the amount of data to be displayed& to restrict it& to selectively choose the number of a data record& to ma'e a distinction between the 'actual' delta data and the data intended for repetition& and so on.Question 9:What is the *ur*ose o) the )un tion '0elete 0ata and 7eta 0ata in a Queue' in RSA7! What e2a tl& is deleted!Answer:.ou should act with e treme caution when you use the delete function in the delta queue. ,t is comparable to deleting an ,nit-elta in the %W #ystem and should preferably be e ecuted there. 7ot only do you delete all data of this -ata#ource for the affected %W #ystem& but you also lose all the information concerning the delta initiali8ation. Then you can only request new deltas after another delta initiali8ation. When you delete the data& this confirms the LUWs 'ept in the q")* queue for the corresponding target system. 2hysical deletion only ta'es place in the q")* outbound queue if there are no more references to the LUWs.The delete function is intended for e ample& for cases where the %W #ystem& from which the delta initiali8ation was originally e ecuted& no longer e ists or can no longer be accessed.Question 11:Wh& does it ta.e so lon, to delete )rom the delta queue ()or e2am*le hal) a da&)!Answer: ,mport 2lug,n 4555.4 patch /. With this patch the performance during deletion improves considerably.Question 11:Wh& is the delta queue not u*dated when &ou start the :% u*date in the lo,isti s o .*it area!Answer:,t is most li'ely that a delta initiali8ation had not yet run or that the the delta initiali8ation was not successful. ! successful delta initiali8ation (the corresponding request must have <6 status 'green' in the %W #ystem) is a prerequisite for the application data to be written to the delta queue.Question 1":What is the relationshi* between RSA7 and the qRF5 monitor (Transa tion S7Q1)!Answer:The q")* monitor basically displays the same data as "#!$. The internal queue name must be used for selection on the initial screen of the q")* monitor. This is made up of the prefi '%W& the client and the short name of the -ata#ource. )or -ata#ources whose name is shorter than 45 characters& the short name corresponds to the name of the -ata#ource. )or -ata#ources whose name is longer than (= characters (for delta1capable -ata#ources only possible as of 2lug,n 455(.() the short name is assigned in Table "++##>+"T7.,n the q")* monitor you cannot distinguish between repeatable and new LUWs. 6oreover& the data of a LUW is displayed in an unstructured manner there.Question 1%:Wh& is there data in the delta queue althou,h the :% u*date has not &et been started!Answer:.ou posted data in the bac'ground. This means that the records are updated directly in the delta queue ("#!$). This happens in particular during automatic goods receipt posting (6""#). There is no duplicate transfer of records to the %W system. #ee 7ote ?($(@=.

Question 1+:Wh& does the 'Re*eatable' button on the RSA7 data details s reen not onl& show data loaded into BW durin, the last delta but also newl&;added data' in other words' '*ure' delta re ords!Answer:,t was programmed so that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system. Question 1-:4 loaded se(eral delta inits with (arious sele tions< For whi h oneis the delta loaded!Answer:)or delta& all selections made via delta inits are summed up. Thismeans a delta for the 'total' of all delta initiali8ations is loaded. Question 1/:=ow man& sele tions )or delta inits are *ossible in the s&stem!Answer:With simple selections (intervals without complicated Aoin conditions or single values)& you can ma'e up to about (55 delta inits. ,t should not be more.With complicated selection conditions& it should be only up to (5145 delta inits."eason3 With many selection conditions that are Aoined in a complicated way& too many 'where' lines are generated in the generated !%!2 source code which may e ceed the memory limit.Question 17:4 intend to o*& the sour e s&stem' i<e< ma.e a lient o*&< What will ha**en with ma& delta! Should 4 initiali>e a,ain a)ter that!Answer:%efore you copy a source client or source system& ma'e sure that your deltas have been fetched from the delta queue into %W and that no delta is pending. !fter the client copy& an inconsistency might occur between %W delta tables and the +LT2 delta tables as described in 7ote ?5B=?/. !fter the client copy& Table "++#2"6#* will probably be empty in the +LT2 since this table is client1 independent. !fter the system copy& the table will contain the entries with the old logical system name which are no longer useful for further delta loading from the new logical system. The delta must be initiali8ed in any case since delta depends on both the %W system and the source system. ;ven if no dump '6;##!C;DT.2;D9' occurs in %W when editing or creating an ,nfo2ac'age& you should e pect that the delta has to be initiali8ed after the copy. Question 18<Am 4 *ermitted to use the )un tions in Transa tion S7Q1 to manuall& ontrol *ro esses!Answer:Use #6<( as an instrument for diagnosis and control only. 6a'e changes to %W queues only after informing %W #upport or only if this is e plicitly requested in a note for *omponent '%*1%W' or '%W1W>61#!2,'.Question 19<0es*ite the delta request onl& bein, started a)ter om*letion o) the olle ti(e run (:% u*date)' it does not ontain all do uments< 3nl& another delta request loads the missin, do uments into BW< What is the ause )or this ?s*littin,?!Answer:The collective run submits the open E4 documents to the tas' handler for processing. The tas' handler processes them in one or several parallel update processes in an asynchronous way. )or this reason& plan a sufficiently large Fsafety time windowF between the end of the collective run in the source system and the start of the delta request in %W. !n alternative solution where this problem does not occur is described in 7ote B5B$55.Question "1<

0es*ite deletin, the delta init' #$Ws are still written into the 0eltaQueueAnswer:,n general& delta initiali8ations and deletions of delta inits should always be carried out at a time when no posting ta'es place. +therwise& buffer problems may occur3 ,f you started the internal mode at a time when the delta initiali8ation was still active& you post data into the queue even though the initiali8ation had been deleted in the meantime. This is the case in your system.Question "1<4n S7Q1 (qRF5 7onitor) 4 ha(e status '@3SA@0'< 4n the Table TRF5Q3$T' some entries ha(e the status 'RAA0B'' others 'RA53R0A0'< ARF5SSTATA is 'RAA0'< What do these statuses mean! Whi h (alues in the )ield 'Status' mean what and whi h (alues are orre t and whi h are alarmin,! Are the statuses BW;s*e i)i or ,enerall& (alid in qRF5!Answer: Table T")*<+UT and !")*##T!T;3 #tatus ";!- means that the record was read once either in a delta request or in a repetition of the delta request. >owever& this still does not mean that the record has successfully reached the %W. The status ";!-. in the T")*<+UT and ";*+"-;- in the !")*##T!T; means that the record has been written into the delta queue and will be loaded into the %W with the ne t delta request or a repetition of a delta. ,n any case only the statuses ";!-& ";!-. and ";*+"-;- in both tables are considered to be valid. The status ;9;*UT;- in T")*<+UT can occur temporarily. ,t is set before starting a delta e traction for all records with status ";!- present at that time. The records with status ;9;*UT;- are usually deleted from the queue in pac'ages within a delta request directly after setting the status before e tracting a new delta. ,f you see such records& it means that either a process which confirms and deletes records loaded into the %W is successfully running at the moment& or& if the records remain in the table for a longer period of time with status ;9;*UT;-& it is li'ely that there are problems with deleting the records which have already been successfully been loaded into the %W. ,n this state& no more deltas are loaded into the %W. ;very other status indicates an error or an inconsistency. 7+#;7- in #6<( means nothing (see note /$@=5/). >owever the value 'U' in field '7+#;7-' of table T")*<+UT is of concern.Question ""<The e2tra t stru ture was han,ed when the delta queue was em*t&< A)terwards new delta re ords were written to the delta queue< When loadin, the delta into the 6SA' it shows that some )ields were mo(ed< The same result o urs when the ontents o) the delta queue are listed (ia the detail dis*la&< Wh& is the data dis*la&ed di))erentl&! What an be done!Answer:6a'e sure that the change of the e tract structure is also reflected in the database and that all servers are synchroni8ed. We recommend resetting the buffers using Transaction G#.7*. ,f the e tract structure change is not communicated synchronously to the server where delta records are being created& the records are written with the old structure until the new structure has been generated. This may have disastrous consequences for the delta. When the problem occurs& the delta needs to be re1initiali8ed.Question "%< =ow and where an 4 ontrol whether a re*eat delta is requested! Answer:Eia the status of the last delta in the %W "equest 6onitor. ,f the request is ";-& the ne t load will be of type '"epeat'. ,f you need to repeat

the last load for any reason& manually set the request in the monitor to red. )or the contents of the repeat& see <uestion (?. -elta requests set to red when data is already updated lead to duplicate records in a subsequent repeat& if they have not already been deleted from the data targets concerned.Question "+<As o) 64 "11%<1' the #o,isti 5o .*it o))ers (arious t&*es o) u*date methods< Whi h u*date method is re ommended in lo,isti s! A ordin, to whi h riteria should the de ision be made! =ow an 4 hoose an u*date method in lo,isti s!Answer:#ee the recommendation in 7ote B5B$55.Question "-<Are there *arti ular re ommendations re,ardin, the ma2imum data (olume o) the delta queue to a(oid dan,er o) a read )ailure due to memor& *roblems!Answer:There is no strict limit (e cept for the restricted number area of the 4?1digit <*+U7T counter in the LUW management table 1 which is of no practical importance& however 1 or the restrictions regarding the volume and number of records in a database table).When estimating FsoftF limits& both the number of LUWs and the average data volume per LUW are important. !s a rule& we recommend bundling data (usually documents) as soon as you write to the delta queue to 'eep number of LUWs low (this can partly be set in the applications& for e ample in the Logistics *oc'pit). The data volume of a single LUW should not be much larger than (5H of the memory available to the wor' process for data e traction (in a /41bit architecture with a memory volume of about ( C%yte per wor' process& (55 6%yte per LUW should not be e ceeded). This limit is of rather small practical importance as well since a comparable limit already applies when writing to the delta queue. ,f the limit is observed& correct reading is guaranteed in most cases.,f the number of LUWs cannot be reduced by bundling application transactions& you should at least ma'e sure that the data is fetched from all connected %Ws as quic'ly as possible. %ut for other& %W1specific& reasons& the frequency should not e ceed one delta request per hour.To avoid memory problems& a program1internal limit ensures that no more than ( million LUWs are ever read and fetched from the database per delta request. ,f this limit is reached within a request& the delta queue must be emptied by several successive delta requests. We recommend& however& to try not to reach that limit but trigger the fetching of data from the connected %Ws as soon as the number of LUWs reaches a B1digit value.