WEBVTT - TM Podcast - Episode 47 00:00:00.850 --> 00:00:06.915 Welcome to episode 47 of the TM Podcast. 00:00:07.355 --> 00:00:11.425 Has been a while, you know why, it's corona times. 00:00:11.500 --> 00:00:19.114 Still what COVID-19 and 2021. 00:00:19.349 --> 00:00:29.997 That let's say didn't stop us from developing but it did stop us a bit from recording new episodes. But this is over. We now also have a remote setup, so 00:00:30.003 --> 00:00:35.879 here we are again and today we talk about something that we developed quite recently. 00:00:36.433 --> 00:00:42.153 Something that we call the error handling. 00:00:42.526 --> 00:00:55.703 And basically what it is, some of the technical backgrounds will be discussed in today's episode. And we have a nice group of guests today. Or guests, hosts, 00:00:56.028 --> 00:00:59.297 participants, whatever you would like to call it. 00:00:59.213 --> 00:01:11.141 We have Patrick, Balazs and Kevin with us and maybe as always Patrick. Can you maybe start introducing yourself, you as a veteran. You may know Patrick from 00:01:11.045 --> 00:01:17.011 the very first episode of the TM Podcast. So that's. But still 00:01:17.222 --> 00:01:22.023 for those of you don't remember Patrick too well, maybe you can introduce yourself. 00:01:22.721 --> 00:01:33.494 Halo, my name is Patrick. I'm working at the consulting organization in the area of transportation management and currently supporting the development team in various areas. 00:01:34.372 --> 00:01:42.568 And Patrick has been working as a development architect also before here so he is more than qualified, 00:01:42.839 --> 00:01:52.615 to answer the questions. No answer questions but actually Patrick will ask the questions today and we will answer. Balazs can you maybe also add some words about you? 00:01:52.616 --> 00:02:08.165 Sure, I'm Balazs and I joined TM development team only in March last year so I'm quite new here but I have some, I have almost ten years of ABAP experiance already, so 00:02:08.167 --> 00:02:21.927 technical part in a way is not new to me but I'm new to the TM. Nevertheless I had the chance to work amongst other topics on this error handling and I'm very excited to record my first 00:02:21.754 --> 00:02:22.961 TM Podcast episode. 00:02:22.661 --> 00:02:33.417 We're really happy to have you on board. On board of this podcasts episode but of course also in development. And Kevin can you also say some words about you? 00:02:34.150 --> 00:02:47.262 Sure. Also very warm welcome from my side. My name is Kevin and I am now since May 2020 developer in the TM community. 00:02:49.137 --> 00:02:59.893 I am quite new to the ABAP language and to the TM processes, so I'm looking forward to this episode today about error handling. 00:02:59.593 --> 00:03:09.772 Thank you and a very good position to ask questions right, if you don't have been involved. Today our roles. I wasn't introduced myself, I am Bernd 00:03:09.628 --> 00:03:21.688 from the Order Management Team, one of the architects it that area and has been working in TM for a while and you may have heard me in previous TM Podcast episodes already. 00:03:21.472 --> 00:03:28.562 And today our setup is a bit different so, Patrick and Kevin 00:03:28.526 --> 00:03:34.872 will ask the questions and Balazs and myself will try to answer them. 00:03:34.752 --> 00:03:44.528 So that's that. I will hand over to Kevin, Patrick, to the two of you. What do you want to know about error handling? 00:03:44.721 --> 00:03:51.018 What is error handling? No, just kidding. 00:03:51.649 --> 00:04:02.898 When I work for some customers, I sometimes have the problem that when for example messages arrive in the system that they fail and 00:04:02.916 --> 00:04:12.440 basically I cannot correct the actual error in that area. I wonder if there's some news in this area. 00:04:12.663 --> 00:04:20.613 Maybe some improvements in the standard system that helped me here to improve the overall handling? 00:04:20.871 --> 00:04:24.765 What a coincidence, Patrick, exactly for the problem 00:04:24.819 --> 00:04:34.043 we developed this error handling. So what is the overall idea of that error handling? 00:04:33.887 --> 00:04:43.441 I mean all kinds of errors but this what we call error handling here it has at least the starting point in exactly the process you described. 00:04:43.496 --> 00:04:52.286 So you have received a message, electronic message, so not a fax or something, an electronic message and 00:04:52.744 --> 00:04:58.674 unfortunately there are errors in that message. For example there's a typo in the ID 00:04:58.903 --> 00:05:06.895 of the product that's referred or it refers to a purchase order 00:05:06.865 --> 00:05:15.211 that you don't have or that you don't detect. And what so far happens is that goes back into the queue and to forward error handling 00:05:15.175 --> 00:05:22.320 and that's it. And the technical user can then basically go and try to solve the problem. 00:05:22.525 --> 00:05:28.064 In the process of the coinovation project that we had, 00:05:28.059 --> 00:05:36.910 we had to find a solution for exactly that problem. In the project what we heard is that, 00:05:37.024 --> 00:05:49.373 10-15% of the messages do have some errors and if now 10-15% of the messages go into forward error handling a technical user has to solve them. That's quite a job, 00:05:49.463 --> 00:05:56.025 quite a challenge. And also I mean this classic behavior that goes into 00:05:56.374 --> 00:06:03.656 the queue, that means in the end if you have an order with hundreds of items if there's one 00:06:03.873 --> 00:06:08.457 tiny little bit wrong for one of the items, 00:06:08.476 --> 00:06:18.505 product ID or something, the complete message is rejected. Which is also a problem because a possible workaround of course is that you record this 00:06:18.637 --> 00:06:28.528 document then manually, but then you also have to enter the 99 or 999 items manually which are actually completely correct in the message. 00:06:29.039 --> 00:06:35.156 And to address that issue we introduced error handling. So what it does is 00:06:35.384 --> 00:06:42.553 you receive a message with a error or with multiple errors and even so it has 00:06:42.764 --> 00:06:48.358 some errors and we come to that what's supported it and what not, later it is, 00:06:48.586 --> 00:06:53.441 you have a certain error, you can still save the document so all the other 00:06:53.802 --> 00:07:00.730 999 items and all the rest of the document is saved together with that faulty item. 00:07:01.963 --> 00:07:08.716 Still you have an error. So it is not that we can just store it without any 00:07:09.354 --> 00:07:23.877 extra caution, so this error is identified and persisted, let's say, as a part of the document as a clear error and the document is blocked, 00:07:24.304 --> 00:07:33.636 at least for the stops which are affected by that item. So now the new situation is, you receive a error with a message, 00:07:34.526 --> 00:07:49.284 or message with an error. Is that the same thing? No. You receive a message with an error and you can now store it. It is visible to business users and the document is stored with an error and the end user can now go 00:07:49.500 --> 00:07:55.130 and can correct the error. Either by enter for example if the product ID is wrong, 00:07:55.546 --> 00:08:04.396 you can identify that and you can for example correct it. Because you know that the supplier is always sending that message with that wrong product ID. It's always the same error. 00:08:05.833 --> 00:08:14.768 You can also call your supplier and say "OK, see, here in that item that reference for example, this purchase order, is wrong, can you please check 00:08:15.117 --> 00:08:21.913 if you don't have the correct number" and then your supplier sends an update for example, and the error would be gone. 00:08:22.520 --> 00:08:33.132 Or you can also for certain errors where the for example master data is not yet created, you can also do something that we call a retry. But in the end 00:08:34.568 --> 00:08:37.969 errors which are user solvable, 00:08:38.528 --> 00:08:49.038 (is that a word?), solvable by a business user are now visible to business users and they can fix them themselves. And once errors are fixed 00:08:49.279 --> 00:08:54.464 the document is also unblocked automatically and everything goes on, 00:08:55.408 --> 00:08:59.325 as there was never error before. So that's the idea. 00:08:59.855 --> 00:09:08.826 So this means instead of, let's say, keeping the message in the queue we try to process 00:09:08.760 --> 00:09:19.642 the message and create or update the document but only the bits and pieces of the message which can be processed and the bits and pieces which contain errors 00:09:19.534 --> 00:09:22.400 are however stored as error. 00:09:22.340 --> 00:09:30.909 So that big difference compared to the former world is that we really create the document in TM instead of letting just the message fail. 00:09:30.988 --> 00:09:39.670 Exactly, exactly the point. So you see the document, now you have a chance to correct it also without being 00:09:39.514 --> 00:09:46.995 SMQ2 or whatever Q-monitor transactions you're using. Users, but the business users, 00:09:46.906 --> 00:09:53.311 can go, can identify an error and can more or less independently resolve them. That's the idea. 00:09:54.153 --> 00:10:05.786 Does it then completely replace the old logic, the old forward error handling and postprocessing office, or is it something which comes additionally to that. 00:10:05.918 --> 00:10:15.292 We think we should then also come to the type of errors because that's not a bold statement, right, so we replace forward error handling. That's, 00:10:15.755 --> 00:10:18.747 unfortunately it's not the case completely, so. 00:10:19.072 --> 00:10:27.058 We address certain defined errors. We may also come later to what we call error categories. So for every error that we 00:10:26.992 --> 00:10:36.071 handle there is a clearly defined scope for the error. What is the error, how can it be resolved et cetera? 00:10:36.072 --> 00:10:42.675 And we have quite a list of error categories. Balazs, how many? Fifty something? 00:10:42.375 --> 00:10:45.067 Something, something like that, yeah. 00:10:45.103 --> 00:10:59.182 But still there are more possible errors. For example if we receive a message that refers to a document type that we don't know, that is nothing we can handle here because no business user could solve that. 00:10:59.050 --> 00:11:06.507 You could not just create a new document type or something as a business user or just pick 00:11:07.109 --> 00:11:17.786 a different document type. Because we would have issues to create a document in the first place. So there are still errors that would go into forward error handling. 00:11:18.105 --> 00:11:25.718 Basically that are all the errors that we do not explicitly catch in an our new error handling. 00:11:26.206 --> 00:11:32.773 However that number of errors that we handle in our error handling is... 00:11:32.960 --> 00:11:44.437 I think will grow over the years to come, decades maybe even. But we will never, let's say, completely replace forward error handling. 00:11:44.569 --> 00:11:49.538 Still if you have technical issues, really 00:11:49.635 --> 00:12:04.399 deep technical configuration that is missing or wrong that's nothing. That's really it focuses also business users. So errors that a business user can solve. It's nothing, not just another UI for the technical user but this is really for business user 00:12:04.802 --> 00:12:06.580 handleable errors. 00:12:06.833 --> 00:12:12.523 OK. And everything else is then handled by the old world so to say. 00:12:12.662 --> 00:12:22.161 Exactly. That sounds now like strict limitation but than again if you look into the 10-15% of the errors that we for example leart 00:12:22.547 --> 00:12:35.754 from the project partner that we worked with, the vast majority of source errors, at least after a certain setup phase, are master data errors, wrong references to purchase orders 00:12:35.718 --> 00:12:39.179 or typos whatever in product 00:12:39.234 --> 00:12:46.853 or business partner IDs. That kind of errors. So I think with that limited number of errors we still 00:12:46.961 --> 00:12:54.514 expect to catch the majority of the things that today end up in forward error handling. 00:12:54.923 --> 00:12:59.592 OK. And with which release is this functionality coming. 00:13:01.239 --> 00:13:11.544 The error handling, Balazs, it comes with S4? So that's a S4 exclusive thing. It comes with 2020. 00:13:11.851 --> 00:13:16.904 So it's not 2009 anymore. Now it's 2020. Right? Because 2009 sounds 00:13:17.037 --> 00:13:28.081 eleven years old. That's why it's now 2020. And it comes with feature pack zero already. Right? We have some features coming with feature pack one. 00:13:30.389 --> 00:13:43.284 FP1 of S/4 2020 there is quite some more features within and the error handling is more or less completely delivered with FP0. Right, Balazs? 00:13:42.984 --> 00:13:57.886 Yes, that's right. So there are some improvements that we did in FPS1 and most likely there will be some additional improvements in the FPS2 but the core concept is delivered in 2020. 00:13:58.271 --> 00:14:07.056 Right, right. And the stuff that we, the enhancement that we had is also available as note. However I think anyway for 2020 00:14:06.978 --> 00:14:18.509 going on FP1, feature pack one, is a good idea because there is massive development that we had to add. So for production I think it's a good idea to 00:14:18.768 --> 00:14:25.930 go for FPS1 if it comes to error handling. But available, technically available it's already with feature pack zero. 00:14:26.676 --> 00:14:40.857 OK, so if we would go down one level deeper regarding the different error we can catch or we can handle with this concept. So you said technical errors that's a completely different story but 00:14:40.809 --> 00:14:45.496 what kind of errors would then be the majority what we currently handle with this concept. 00:14:45.490 --> 00:14:49.384 Maybe I can start and Balazs you can 00:14:49.558 --> 00:14:58.902 take over if you like. So basically so far we foresee three main categories of errors. First one 00:14:59.113 --> 00:15:04.641 beeing the master data errors. So I refer to a non-existing 00:15:04.821 --> 00:15:16.250 or not yet existing master data object. For example my product that I refer to in my item is not there. 00:15:16.695 --> 00:15:28.617 The, I don't know, certain business partner that I refer in my freight order or consignment order is not known in my system yet. That kind of errors 00:15:29.260 --> 00:15:32.841 is called master data errors. 00:15:32.830 --> 00:15:39.517 Then we have another class of errors. And for that master data errors, I think, we have in itself 00:15:39.620 --> 00:15:49.090 30, 40? 30 maybe. It is really a majority of our error categories. 00:15:49.102 --> 00:16:02.658 So for example. It's a product on the item. It's the business partner or a certain business partner on route level. It's business partner on the business partner tab. It's the business partner on item level et cetera. So, more or less for every single 00:16:02.827 --> 00:16:12.375 master data object, on every single BO node or what we call data node in this context here, 00:16:12.526 --> 00:16:24.844 we have master data error category. The second major category as reference errors, and maybe Balazs, you want to add some words on what that is? 00:16:24.640 --> 00:16:38.941 Sure. So a reference error, as it's name says, is created when the processed message that references a document that does not exist in the system. 00:16:38.689 --> 00:16:48.604 This might be a TM document or this could be document in the ERP referencing for example a purchase order for 00:16:48.472 --> 00:16:56.800 which we don't find anything with the given ID and in this case we create a reference error. 00:16:56.734 --> 00:17:04.756 Maybe we should also note that some master data errors can also trigger reference errors so, 00:17:04.853 --> 00:17:07.124 we have for example, 00:17:07.202 --> 00:17:19.791 when we're looking for a purchasing order we also consider some information such as the product IDs. 00:17:19.647 --> 00:17:30.901 And when the product ID is not found, in addition to the master data error we also create a reference error because if the product. So even if the document ID of the purchase order matches 00:17:30.728 --> 00:17:36.820 if the products that are included do not match then we still create this reference error. 00:17:37.740 --> 00:17:41.189 That's a very good point. Yes, it can also be a combination of reference errors. 00:17:41.171 --> 00:17:48.232 It can also be a list of master data errors. So one item can be, I don't know, could have like ten 00:17:48.064 --> 00:18:00.112 or maybe not ten but five different master data errors and then also, most likely then also the reference error. Because if I cannot really identify the item I also cannot identify the item of the 00:18:00.022 --> 00:18:04.342 ERP document and then finally the freight unit as well. 00:18:05.670 --> 00:18:12.460 OK. That's the reference error. Anything else on the reference error, Balazs? On high level? 00:18:14.353 --> 00:18:23.240 OK. Maybe we come to this life cycle of how the life, day and the life of a reference error, 00:18:23.433 --> 00:18:24.695 maybe later anyhow. Exactly. 00:18:25.272 --> 00:18:35.283 Than we have something maybe like a spare category of what we called an advanced error. So far I'm not even sure if we delivered something in that 00:18:35.518 --> 00:18:38.107 main category. 00:18:38.378 --> 00:18:52.811 But that's more for more complex things like. For example now we are, that's future, but that may be a chosen vision, we are curently doing a prototype with some students on if you have geo-distance determination errors 00:18:53.989 --> 00:19:06.476 that those also end up in the error handling. Again this is nothing that we delivered. That's something that we tried out, but that would go into that advanced error category. It's not a master data error per se, it's definitely not a reference error. 00:19:06.386 --> 00:19:15.772 And if you don't know what kind of error it is it is an advanced error. So, in the end that's more like an open category for more 00:19:16.115 --> 00:19:21.529 complex stuff. Maybe also something for enhancement and we'll talk about enhancement definitely later. 00:19:21.932 --> 00:19:32.952 Yeah so, wraping up once again, so we have master data errors that's any field on any node that refers to master data that we can not find. 00:19:33.253 --> 00:19:41.292 We have the reference errors and we have the advanced errors. And maybe one more word about the master data errors. 00:19:42.164 --> 00:19:55.239 What we do. So what happens, if I receive a message with a faulty for example product ID, in the item, then we leave in the actually item field, we leave the product ID empty. 00:19:55.582 --> 00:20:09.240 Why is that? In most cases leading fields is anyway GUID, the key where we refer to our master data objects and I mean if you don't, determine the 00:20:09.770 --> 00:20:22.665 ID correctly how, what kind of key could be right there? And that would break up everything. So in the end the product ID is kept empty in the item and you have now an error 00:20:22.605 --> 00:20:31.787 and then we talk about how I see it a little later. In the document and which exactly states you have an error on this item 00:20:31.763 --> 00:20:32.844 for a product field. 00:20:34.629 --> 00:20:45.265 OK, maybe that's enough, high level about the categories or types of errors that we have. 00:20:46.119 --> 00:20:53.509 But this means, so that the type is actually only a grouping of the individual errors, correct or is it? 00:20:53.852 --> 00:20:59.783 Yeah, what I refer to, or maybe I was not too precise when I said error category. 00:21:00.084 --> 00:21:12.937 That's actually maybe a jump a bit ahead but error category in the error handling case here that's really a combination of 00:21:13.736 --> 00:21:19.492 the field that has issue and the node. For example 00:21:19.788 --> 00:21:28.013 the product item, our product field on our item level, that is one error category. The shipper field on our item that's another error category. 00:21:28.429 --> 00:21:37.995 The consignee field on the item or ship-to field on the item that's another error category. So really every combination of node and field 00:21:38.265 --> 00:21:47.279 that's an own category. If we talk about reference errors we also have, it's not just there is a reference error but we know that's a 00:21:47.772 --> 00:21:53.726 freight unit reference error or maybe you can mentione some more example here, Balazs? 00:21:53.426 --> 00:21:54.940 Yes, so we have. 00:21:54.640 --> 00:21:56.136 Some error categories? 00:21:55.836 --> 00:22:08.821 For example we have freight orders referencing non-existing consignments. Or freight orders referencing consignments which themselves have an error. 00:22:09.242 --> 00:22:11.669 Have errors. 00:22:12.733 --> 00:22:13.790 So yeah. 00:22:13.540 --> 00:22:14.578 Go ahead sorry. 00:22:14.278 --> 00:22:22.768 So this, I just wanted to add that this master data error versus reference error this is 00:22:22.636 --> 00:22:35.375 mostly technical grouping. So from the user point of view it doesn't really matter. There is this tab where we display these error messages and they look the same 00:22:35.237 --> 00:22:43.235 they have obviously different semantics but it's not really, 00:22:43.698 --> 00:22:53.408 It's more a way that we technically divided these error categories into master data and reference errors. 00:22:54.677 --> 00:23:06.977 Exactly. Well you'll see that. I mean. Maybe we can also jump ahead a little bit. So every error category that really identifies a certain error on a certain node has a refering handler class, that. 00:23:06.989 --> 00:23:16.092 We come to the details of that class later but it's a one to one. So for every single error category there is a error class and most likely, 00:23:16.406 --> 00:23:20.365 99% of the cases there is also a specific message ID, 00:23:20.378 --> 00:23:34.198 So user message with a long text, where the options how to resolve the errors are described and that is of course. For master data it's a little bit similar, but it's not identical. 00:23:34.282 --> 00:23:38.170 That is what an error category actualy is. A very detailed. 00:23:38.543 --> 00:23:44.546 It's the field level, node field level the error. What we talked about is 00:23:44.402 --> 00:23:50.687 master data error, reference error and advanced that's more let's say a logical grouping. You can only find them 00:23:50.537 --> 00:23:58.667 if you look into the class hierarchies. Because master data errors have a lot in common, that's why the handler classes have a lot in common. 00:23:58.661 --> 00:24:07.452 Like 99% of the code or 90% of the code is shared for them. However as Balazs said for the end user anyway an error is an error, 00:24:07.849 --> 00:24:18.929 and there's a certain action set etc. To handle it, that's more a logical categorization of categories. But what's a group of categories? Super category. I don't know. 00:24:19.140 --> 00:24:22.138 Meta-category. Whatever. 00:24:23.737 --> 00:24:36.260 OK, so that the actual type of what we just described the master data, the reference and advanced errors is just a kind of as you said logic grouping of the individual error categories, where we will talk about 00:24:36.206 --> 00:24:42.004 I think in a few minutes a bit more in a detail. OK, now I got it. 00:24:42.131 --> 00:24:52.670 Good. For me still what's not 100% clear is how do we get these errors? So let's. I receive a message. OK, that's processed by the system and finaly 00:24:52.557 --> 00:24:58.067 I need. So what is an error and how do we create them basically? 00:24:57.772 --> 00:25:12.320 OK, so maybe that's a good point, that's a good idea. So maybe we can go to the day in a life of an error. So maybe in start with the creation of course. So let's say we receive a message 00:25:12.272 --> 00:25:14.231 and by the way, 00:25:14.291 --> 00:25:27.349 come to that a bit later. It has certain limitations so that does not work for any message in any context. We will come to that in more detail later. So you receive a message and in that message you have for example. 00:25:27.782 --> 00:25:33.213 In the items you refer to a product which does not exist in your system. 00:25:33.580 --> 00:25:41.873 So what happens? First of all it goes into the normal message processing. And from there, 00:25:41.969 --> 00:25:53.951 it goes into an engine which is called the update handler, which is for those messages taking care of creating correct document chain. And in this update handler 00:25:54.017 --> 00:26:03.668 the check of master data, of existence of master data is performed. Right, Balazs? 00:26:03.932 --> 00:26:11.978 Yes if you want to be a bit more precise when there is a component called the inbound agent 00:26:11.949 --> 00:26:21.136 before the update handler so to say. And that's were this jackson on the different reference master data object takes place. 00:26:21.329 --> 00:26:30.017 OK, thank. I want to be precise but I can't so that's why it's very good to have you here. 00:26:30.420 --> 00:26:36.135 The inbound agent so it's a master. First of all it's been checked if it detects some master data. 00:26:36.544 --> 00:26:46.945 And if he recognized that master data and so far if he did not do then we would go to an error and go back into forward error handling. Now I think. 00:26:47.486 --> 00:26:52.948 Or maybe it's best, Balazs, I mean you wrote that part. Maybe you do describe what comes next. 00:26:52.648 --> 00:27:02.496 Yeah. The master data errors are detected in this thing called inbound agent. And then... 00:27:02.971 --> 00:27:10.002 The next step is another component of this update handler called the service first aid, where we 00:27:10.218 --> 00:27:18.540 do a lots of things. We also do this thing called freight unit matching. Where we do 00:27:19.334 --> 00:27:26.394 the matching of the reference documents and link them between each other. 00:27:26.731 --> 00:27:31.442 And this is the place where we check for reference errors for example. 00:27:32.001 --> 00:27:43.526 And after this, so after we have the inbound agent and this reference errors there's, then we gather everything and 00:27:44.007 --> 00:27:51.068 we create our document. If errors are detected then we also create them. 00:27:51.236 --> 00:28:04.930 Because maybe I also jump a bit ahead. These errors are stored in the TOR BO just as everything. All the other information just like items, just like stops and so on. 00:28:05.165 --> 00:28:15.897 These error information is also part of the business oject. So then we also give this data to the update handler and then we store everything including the errors. 00:28:16.781 --> 00:28:20.422 So that's how the document with the errors is created. 00:28:20.489 --> 00:28:32.013 So basically this ID, this faulty ID, is removed from the item in that example, right? And instead or based on that detected error the item field is cleaned up, 00:28:32.026 --> 00:28:40.817 but also an error node is instantiated. We come to the exact BO modeling a bit later, but 00:28:41.364 --> 00:28:47.409 that's basically what happens. And then the item is created without a product reference. 00:28:47.710 --> 00:28:53.496 Plus we create this error instance. That is how it all starts and then you can save. 00:28:54.560 --> 00:29:01.464 Also important maybe, if you create such an error instance we also create a block, 00:29:01.645 --> 00:29:14.564 so that because there is no item, or if you have such an incomplete item obviously there is a problem for execution. Maybe not for planning but for execution. That's why we create an execution block. 00:29:14.582 --> 00:29:19.155 But this block only blocks the stops which are 00:29:19.287 --> 00:29:24.863 linked to that item. So if I have for example multi drop 00:29:25.056 --> 00:29:32.849 and that only affects my second drop in the inbound scenario, my first stop is fine but I create a block for the second stop. 00:29:33.427 --> 00:29:40.433 If that item refers to the second stop. Then the document is saved. Item with an empty product, 00:29:40.974 --> 00:29:50.119 block entry on stop level, plus the error handling instance in that BO node. And we'll come to the details of that later. 00:29:50.811 --> 00:29:56.002 But this means that this error must be identified by, 00:29:56.081 --> 00:30:04.223 so to say, an external caller and not the business objected itself. So the business object does not recognize the error itself? 00:30:04.481 --> 00:30:12.347 But it is rather as you said the inbound agent for example who creates that error in the business object. 00:30:12.287 --> 00:30:18.735 Exactly, yeah, clearly, that's as simple as that, so far I mean 00:30:18.867 --> 00:30:29.317 maybe we'll come later also to an outlook and they might be other sources for errors but so far the concept is the error is detected, 00:30:29.383 --> 00:30:35.800 outside the core BO model and then the BO model knows how to handle but not how to detect it. 00:30:36.474 --> 00:30:37.609 OK 00:30:39.737 --> 00:30:48.161 That's how it starts and maybe if you'd like we can also address it, take that from a user perspective maybe. 00:30:49.760 --> 00:30:56.772 Continue the journey of that error so what happens now is the document is saved. 00:30:57.127 --> 00:31:09.079 This item has an empty product, there's an error entry and there's a block and it is solved. Now first thing is how can I recognize or how can I find those documents. 00:31:09.650 --> 00:31:18.591 And this is basically as I said we have blocks for the document and basically 00:31:19.006 --> 00:31:31.438 we are using the block categories which, okay, then master data in reference and in advance comes on place again, so not every error category has its own block category but we have only, 00:31:31.463 --> 00:31:38.811 block categories like master data or reference error. So you can in your POWL, you can as, I mean, 00:31:39.082 --> 00:31:50.944 already today you can select documents by block category and that now also is used to identify documents with the block category, for example master data or reference error 00:31:51.155 --> 00:32:00.228 so in POWL business user can check for example all faulty documents or ones with reference errors or ones with master data errors. 00:32:00.396 --> 00:32:08.508 And then we have a list, then we have first a list of all documents with unresolved document errors. 00:32:08.965 --> 00:32:17.519 OK, that's a good starting point but it's not solved yet, so then user can go into the, for example, freight order. 00:32:17.466 --> 00:32:28.326 We identified this master data, product, let's stick to the product example. We can now go into the document and there is a special tab Error handling, 00:32:28.345 --> 00:32:31.343 Right. And in there. 00:32:31.866 --> 00:32:46.113 First of all you can go into a document to go into the Error handling tab and there you'll see the list of errors. And maybe, Balazs, do you want to say more words about Error handling tab and what it provides then. 00:32:46.053 --> 00:32:58.275 Yes. So basically you have a list of all the errors that have been identified for this document and then depending on 00:32:58.402 --> 00:33:05.865 the error category you have different options to solve this. 00:33:06.556 --> 00:33:10.233 Let's say, the simplest thing 00:33:09.988 --> 00:33:22.221 for example a reference error, the document is referenced to the ERP document which for some reason it's not yet available 00:33:22.006 --> 00:33:27.666 but then it appears in the system. 00:33:28.219 --> 00:33:34.161 Then we can simply solve this by a retry so that's one option. 00:33:33.861 --> 00:33:42.436 Maybe one more thing you can start with is for every error you also have a description, right, so you have lists of errors and then you can 00:33:42.418 --> 00:33:51.221 press on Describe I think it's something like that and then you will get a long text or a message and it's also tries to highlight the affected node data 00:33:51.060 --> 00:34:05.042 like if you have an Error handling tab opened and the Items tab opened then, and you press Describe that you would also see that the red surrounding on the product item field 00:34:05.050 --> 00:34:10.234 and would get a message for >?now? says OK, 00:34:10.415 --> 00:34:25.010 product ID is wrong for that field and it also tells you what was wrong product ID so we also store the faulty data because it might give you a hint to correct the data. 00:34:25.485 --> 00:34:27.113 and instead faulty 00:34:27.468 --> 00:34:41.199 With that message a long text that a user gets information how to resolve the error as mentioned. We try to address end users. One of the options that we typically have is a retry. 00:34:41.932 --> 00:34:46.384 We just take the value as it has been sent and try to, 00:34:46.469 --> 00:34:56.161 if it works now, so for example the product maybe it's something where that master data is not yet created. It's not a typo but your supplier 00:34:56.150 --> 00:35:06.833 did send the message so fast that you didn't even have the time to create master data, part of it and that's why you, you just have to wait 00:35:06.834 --> 00:35:16.922 half an hour later, some master data has been created then you press Retry and everything is fine, in this case. That's one option to solve it. 00:35:17.266 --> 00:35:20.504 But I thing there are more options typically, right Balazs? 00:35:20.204 --> 00:35:25.053 Yes, so let's say we really had a typo for a product ID, 00:35:25.096 --> 00:35:37.420 and then next to the error message you have an input field and then you can actually correct this faulty value and 00:35:37.450 --> 00:35:45.754 you also have a nice search help which is so smart that depending on the error category 00:35:45.695 --> 00:35:59.106 you get relevant search help so if you have a wrong product ID then as soon as you start typing you get an search help for an products and the same for example for locations. 00:35:59.948 --> 00:36:10.764 That's another option but you can also correct this field on the item itself or on the faulty node, 00:36:10.849 --> 00:36:16.581 so you can actually, you don't have to necessarily do this in the error handling tab, 00:36:16.810 --> 00:36:25.702 but you can go into the your items or your stops and then correct this data there. That's also an option. 00:36:27.019 --> 00:36:32.481 Exactly, or you call your supplier and the suppliers sends you a new version. 00:36:32.295 --> 00:36:44.655 now with corrected errors and also correct product ID Identies? also disappeared so basically the error disappears as soon as the field has been 00:36:44.475 --> 00:36:49.559 filled with the valid values, so it knows that this item, 00:36:50.058 --> 00:36:55.465 has a problem and also knows what kind of problem based on the error category. 00:36:55.784 --> 00:37:07.676 Add now if this problem on this item has been resolved on whatever way that's a valid product ID in the item then the error is resolved, 00:37:07.784 --> 00:37:10.999 that this error disappears, 00:37:11.096 --> 00:37:23.984 so far we do not store resolved errors that something for the future. Once all blocks are gone, sorry, when all errors are gone, the underline blocks are also removed. 00:37:26.527 --> 00:37:30.739 So ones again, when the message comes in 00:37:31.610 --> 00:37:46.488 the error is detected, the field is cleared in the field, in this what we call data node like: item, stop, route. We create an entry which identifies that error also we have an.... 00:37:47.144 --> 00:37:50.430 but we will comes to BO modeling later, so we create an entry. 00:37:50.906 --> 00:38:00.952 That is an item product error and once for the affected items it is a valid product. 00:38:01.229 --> 00:38:06.018 For a affected business partner node once there is a valid business partner ID, 00:38:06.871 --> 00:38:11.324 key in the end, then the error is resolved. 00:38:11.811 --> 00:38:23.168 Error is, error handler, error instance is removed and also the block finally goes away and document looks like it never had a problem. 00:38:25.356 --> 00:38:39.338 Maybe what's still worth mentioning here, so this actions like retrieve and so on, that is quite flexible so we can offer up to five actions, if I'm correct. 00:38:39.110 --> 00:38:44.644 On the UI that's completely flexible so there we can provide 00:38:44.620 --> 00:38:51.026 different actions for different error categories for the solution. 00:38:51.351 --> 00:39:03.603 That's a good point, we'll come to the technical modeling I think in a minute, but more or less every error category has assigned, that we already talked about, messages, so the end user, 00:39:03.621 --> 00:39:12.965 side of the story, for search help. Something that is more less defined by the error category in the end. 00:39:13.356 --> 00:39:19.064 And also the actions. Balazs have you mentioned up to five I think so far or maximum is two, 00:39:18.950 --> 00:39:23.541 or three, right? That's the retries, very popular, we almost there. 00:39:23.397 --> 00:39:35.830 But what we have one or two example where we have more actions but hopefully we will find other, let's say, actions that help to user to solve the problem and then you could have up to 00:39:35.998 --> 00:39:48.208 the five actions with the button Description and then of course underlying system behavior if you press that button. And then every, OK, now that's disadvangege for error podcast, 00:39:48.449 --> 00:39:59.806 but audio podcast, error podcast but audio podcast that what it was. You have the list of errors on the left hand side with the description and you have Describe button and then you have 00:39:59.962 --> 00:40:08.717 the buttons to solve the error like Retry and then you have input field where you can just enter values where applicable, of course, that is not 00:40:08.760 --> 00:40:16.901 always possible, but in many, like in master data cases you can just enter corrected master data ID, than those 00:40:16.860 --> 00:40:30.446 corrected data, by the way I also check so I can not just enter anything and then this is goes through, ones again check if this is a valid value and if not you can get an error message that this is that you failed to correct the field. 00:40:31.059 --> 00:40:33.943 And then you have to try again. 00:40:36.203 --> 00:40:45.114 But this means errors are usually corrected so to say manually by a user, except you get an update via message, but then it also, also corrected so 00:40:45.451 --> 00:40:51.970 You can either change the let's say the faulty value to the correct one. 00:40:52.265 --> 00:41:00.413 Or in case of reference errors or master data which is not yet there then it can also happen that is if the error is 00:41:00.366 --> 00:41:07.570 corrected automatically so to say, because you enter for example all the actual fields which, which is 00:41:07.889 --> 00:41:13.164 not correct, is now maintained correctly in then the error would also be gone. 00:41:13.303 --> 00:41:21.465 That's a very good point, in the end is there one more option that I forgot to mention, it's mass retry. So in the POWL 00:41:21.476 --> 00:41:31.842 if I'm not wrong, we introduced also Mass Retry button. So you can also select all your consignments, I don't know, they may be restricted 00:41:31.853 --> 00:41:38.697 to a certain supplier or something. So you can select documents and then perform retry on all 00:41:39.106 --> 00:41:49.429 errors of that node and then it resolves as much as possible. Of course if the retry still fails and fails, but instead you can 00:41:49.802 --> 00:41:55.342 auto mass retry from POWL. I think we even have a report but I forgot 00:41:55.655 --> 00:42:04.854 it's name. I wrote it myself. So maybe we can check that and also provide that but if you search for reports with error in it 00:42:05.396 --> 00:42:14.625 that should be possible. So you can also just run a report that can select all documents with errors 00:42:15.016 --> 00:42:24.997 and would then do a retry automatically in the background. Good that you asked, that I would have forgotten to mention it. In POWL mass retry is also available. 00:42:26.217 --> 00:42:38.716 Because retry is something that you can just blindly do, I mean, we store the original value, but of course it only makes sense for not yet created data, but for example for the reference errors. 00:42:39.082 --> 00:42:48.528 If you have that kind of problem frequently that the... because in the end maybe coming to the reference error. 00:42:49.063 --> 00:43:01.826 It is not enough that you have for example the purchase order but there must be freight units which refers to the that purchase order in the end. Maybe for some reasons the freight units are not yet created. 00:43:02.199 --> 00:43:08.382 Then retry would work even though ??? a number. 00:43:08.900 --> 00:43:23.826 Purchase order number did not work before but after freight unit creation it would work. Same if you already receive a freight order and that points to consignment and if this consignment just arrives five minutes later, it can be solved automatically, 00:43:24.000 --> 00:43:32.058 by automatic retry as well. So that's also very efficient option of course for applicable errors. 00:43:32.485 --> 00:43:37.971 So that's not.... wouldn't work for everything I guess. Typo is a typo 00:43:39.293 --> 00:43:45.146 But for everything else which really can be solved by retry, that's a nice way of solving it. 00:43:46.144 --> 00:44:00.331 And then once you click on Retry or you change the data and say retry, then the message is adapted and you send it again? Or how is this error then also resolved? 00:44:00.085 --> 00:44:04.699 This retry is... maybe we'll come. 00:44:05.240 --> 00:44:12.048 We'll come to the details also of BO ??bottling?? a little bit later, but when we store such an error 00:44:11.965 --> 00:44:22.943 We store also as mentioned we remove the data from the item for example, from the data node, but we store with the error original value that was a part of the message for example. 00:44:23.610 --> 00:44:31.165 For an example, I don't know. You receive only item product 123. 00:44:31.289 --> 00:44:40.475 And this is not yet there. We store that. In this error instance we store that product 123, value. 00:44:42.366 --> 00:44:50.681 If you now press Retry, it will just try to mimic> that you enter produce 123 into the product field. 00:44:51.003 --> 00:44:59.729 In the end. So there is no new version of the message or something, but it just the way it has been sent originally. 00:45:00.241 --> 00:45:14.400 It tries to kind of re-enter that the data and check if it's now a valid value. But it does not goes truly complete error handling process, right Balazs? Not to the message processing completely, right Balazs? 00:45:14.411 --> 00:45:16.485 It more mimics the user entry. 00:45:16.412 --> 00:45:25.353 Yes, it's depending on the error category, so for some 00:45:25.293 --> 00:45:36.043 some categories really trigger new processing of the message like reference error for example but for master data, that's right what you said. 00:45:39.415 --> 00:45:52.483 As way after deep sort now I remember the name of that retry report. It's /SCMTMS/TOR_RETRY_ERRORS. Sometimes it's good to think deep enough then you remember all the report names. 00:45:59.683 --> 00:46:03.078 That's maybe for the life cycle of an error. 00:46:03.541 --> 00:46:13.401 So you said that blocks are usually created in case there's a document error. Is that correct? Does it... 00:46:13.804 --> 00:46:27.517 You have the errors on let's say different levels so you might have an item error and you might have an a business partner error and all are creating then root logs or you mentioned also stop based blocks. So can you maybe just 00:46:27.421 --> 00:46:32.348 say some words on that? So how all those stops and blocks are basically created. 00:46:32.078 --> 00:46:42.480 I think we still owe kind of owe audience also maybe a podcast episode about blocks but in the end. Right, we have a block 00:46:42.750 --> 00:46:45.899 defines sorted certain, 00:46:46.326 --> 00:46:53.061 document or part of document is blocked for certain activity. Basically we have the planning block that means, 00:46:53.062 --> 00:47:02.171 that's document or that's part of the document, like a stage should not be planned. We have an execution block so I shouldn't execute that part and we have an invoicing block, 00:47:02.244 --> 00:47:13.114 to not invoicing that part. We have that on header level so that's means that complete document this locked, right? We introduced that or we had it already earlier on stage level, 00:47:13.186 --> 00:47:25.835 so like for freight units, if freight unit stage is for example incomplete or so, then this stage is blocked but the other stage which does not have that problem can already be planned and then also executed. 00:47:25.871 --> 00:47:32.463 And now for the sake of the development, we introduced this block also on stop level because we are.. 00:47:32.439 --> 00:47:37.234 we had discussions with the customers and they said that they have cases where 00:47:37.343 --> 00:47:47.125 certains locations are find on the same document, they go to inbound scenario for example plants of mine and 00:47:47.005 --> 00:48:01.319 they don't want to block the complete document just because, for example, you deliver to Berlin and Frankfurt or so. And in Berlin everything is fine and Frankfurt you might have an issue and then you don't want to 00:48:01.223 --> 00:48:15.434 prevent delivery or execution to Berlin, just because later something wrong in Frankfurt, because that can be fixed while truck is moving from Berlin to Frankfurt. That's why we introduced that, 00:48:15.494 --> 00:48:22.206 blocks on stop level now and for every error more less we know for every error 00:48:22.621 --> 00:48:32.349 where it belongs to. For example it belongs to an item and this item is an inbound item them we know the inbound stop needs to be blocked. 00:48:32.440 --> 00:48:46.164 Same if its refers to stop itself, so master data, this location is unknown or so, then also the stop is blocked. But if this refers to a carrier or something which is a header level then the complete document is blocked. 00:48:46.459 --> 00:48:52.173 So depends a bit. And as soon as we create such an error, 00:48:52.420 --> 00:49:05.309 so far we create an execution block that is hardcoded actually. We only differ between master data reference and advance errors but it's also just, let's say, for 00:49:05.442 --> 00:49:11.949 grouping has no technical difference between them and then you have an execution block on stop level or on route level. 00:49:12.887 --> 00:49:20.762 So kind of contacts sensitivity when blocking the document. OK, so only the needed parts are really blocked, OK. 00:49:20.597 --> 00:49:29.832 Yes, as fine as possible, yes. I mean you could still, yeah. But it's bit technically driven to be honest, so for the item we know what's the 00:49:29.797 --> 00:49:41.568 stop reference, for stop in a stage, we know it. But on the header level, might also be cases where you could say OK but it only affects on the first stop or last stop, something but 00:49:41.977 --> 00:49:52.781 so far that would be a complete document block. If we have nice ideas or a customers have a nice ideas on how to make that more granular 00:49:52.673 --> 00:49:57.155 based on clear criteria that we would also be more granular there. 00:49:56.855 --> 00:50:06.824 OK, so this means actually this new concept you can more less handle all the errors which we 00:50:07.143 --> 00:50:17.724 might even think of so far. For example same semantic problems we might have the document has, or the weight is too high and then we created an error or 00:50:17.539 --> 00:50:23.265 this is a concept of blocking the document only or can you only handle certain errors? 00:50:23.091 --> 00:50:31.172 Yes, of course, if you think long enough maybe you can apply it to more areas but in the end there are certain 00:50:31.924 --> 00:50:38.486 limitations or maybe we should call it rules for errors that can be handled with error handling. 00:50:39.207 --> 00:50:46.790 First of all I think we mentioned that already at the begining it should be something that can be used, solved by business user. 00:50:47.410 --> 00:50:59.109 So that's a one rule. So that's why if it's really technical problem which anyway is something for tech-user then forward error handling is a right place for 00:50:59.770 --> 00:51:09.547 technical user. So there is one more semantic decision. Then the second one rule is that of course we need a clear indicator, 00:51:09.649 --> 00:51:19.648 that something is wrong. For example product ID that we do not know that something that we as programmers. 00:51:20.315 --> 00:51:26.408 Yes we as a developers and actually our programs can detect clearly. We say, OK... 00:51:26.829 --> 00:51:38.667 Let's say the product ID is very unlikely to be sent by this carrier, by this supplier or something like that. There is nothing you can code against. 00:51:39.346 --> 00:51:44.429 So either is this an error or not? 00:51:45.409 --> 00:51:58.785 If we must have a clear rule where we can identify that. This is a error situation. For example product ID does not exist. If it exist but it is for whatever reason not suitable that would be 00:51:59.915 --> 00:52:09.018 something to think about at least. What is that clear criteria where you say this is right or wrong, so must be a clear separation. 00:52:09.271 --> 00:52:24.263 and then what holds that faulty creation of the error but also as resolution, so there must be a clear indicator that this error has been solved. If you say the weight problem, if you say, this weight is now OK. 00:52:23.560 --> 00:52:26.522 You need crystal clear indication what OK means. 00:52:28.128 --> 00:52:39.360 I don't know we could talk something like capacity check if you say now do error handling for capacity checks then you would need a clear rule, where you say OK, you have such an error. 00:52:39.380 --> 00:52:54.838 if the capacity is violated then we have an error. If it is not violated then is not an error anymore. Then it would be suitable but you say: Should be OK? But 5% is OK or maybe 7 it's depends. Then it's not a candidate 00:52:55.535 --> 00:52:59.320 for error handling. So there must be a clear rule. 00:52:59.645 --> 00:53:11.158 OK, but it somehow sounds also like, let's say, we have a clear definition of what is the error and when is it resolved for master data error or references errors. 00:53:11.069 --> 00:53:20.021 But when we think about these advanced errors actually we can substitute what not whatever but many additional errors which we I think... 00:53:20.154 --> 00:53:26.319 Yes if. But again there must be a way that we know now the problem has been solved. 00:53:26.662 --> 00:53:31.678 Yes of course it can be more complex than yes or no, but there must be a rule 00:53:32.133 --> 00:53:45.872 so far. I mean, either of course, we also already discussed about manual overwriting kind of errors and as I said this distance error is maybe again not so 00:53:46.053 --> 00:54:00.847 black and white or weight. So there might be more to come, but for the moment I would say as a guideing principle also if you think about let say your own using it's error category maybe for that fields also. 00:54:01.118 --> 00:54:08.232 Then you should have a clear understanding on when do I create error and when do I remove the error. 00:54:08.137 --> 00:54:23.020 Also what is the error that I want to present to my end users. So what do I tell my user how to solve error. If you don't know how to tell it your user most likely it's not a candidate for error handling, because if you don't know how to explain, 00:54:22.997 --> 00:54:26.073 what to tell the user the user will also be lost on how to solve it. 00:54:26.230 --> 00:54:35.159 So if you cannot write a long text message that may be also an indication for a error that is not applicable for error handling. 00:54:35.556 --> 00:54:46.198 Is the error handling actually limited to let's say one field or can I also have a combination of attributes which form the error to say so if i have? 00:54:45.898 --> 00:54:56.607 Combinations of attributes, I would say it's not a problem. Combination of nodes is maybe more of a challenge. We come to the technical modeling I think. 00:54:56.631 --> 00:55:08.197 One of the next steps that we should also discuss the technical modeling and maybe from that it becomes clear what is technical 00:55:08.540 --> 00:55:11.670 surrounding or limitations that we have here. 00:55:12.187 --> 00:55:22.042 OK, because we also talked about this kind of error category and I think you also mentioned sometimes the kind of handler classes and so and so. 00:55:22.403 --> 00:55:30.779 There seems to be some error category specific implementations or how? How is that over all concept? 00:55:31.026 --> 00:55:32.690 Yes, so every error 00:55:32.768 --> 00:55:44.065 in the end, what. Maybe we can just slightly, slowly moving over to the technical part of the modeling. And maybe also come to 00:55:43.939 --> 00:55:48.974 handler classes and what they handle. But in the end more or less all, 00:55:50.285 --> 00:56:04.832 all steps in the life cycle of such an error are handled by error handler methods, class methods. So you have such a handler class for error category and then is for example called to check if the error is resolved. 00:56:06.335 --> 00:56:14.868 It is also called if you enter a value. That you make sure that a value is appropriate 00:56:14.970 --> 00:56:28.724 for your handler class or for your error. So I don't know. If your numeric field or so that you then validate the input, that the input is numeric or whatever. 00:56:28.695 --> 00:56:35.575 If it really fits. The F4 helps are described or defined by the error handler class so more or less everything. 00:56:35.761 --> 00:56:49.450 In the end the action. The actions, the names, the icons. All that comes from the error handler class. The handling of the actions as well. So you have it more or less in full control. The only thing that you do not do in the handler class itself is the creation of the error. 00:56:49.636 --> 00:56:54.371 Obviously. Because I mean to create the error 00:56:54.912 --> 00:57:00.783 and identify the error handler class, that's catch 22, right? If the error handler class 00:57:00.675 --> 00:57:13.263 which depends on the. Or the category would also be responsible for creating the error, that will be a catch 22. So in the end that is something else so that we come to it later there is some coding that you can 00:57:13.559 --> 00:57:19.808 create your errors in the message processing in the end. 00:57:19.508 --> 00:57:31.730 What it means, for every error category. And every error category is really the smallest piece so to say because it really defines unique error. 00:57:31.658 --> 00:57:40.731 There is a class which actually defines the context of this error and the additional information and characteristics. 00:57:40.431 --> 00:57:51.265 Everything. Exactly, so for every error category there's a class that has no other job that handling executor errors, but all aspects of that error. 00:57:52.059 --> 00:57:56.198 We come a little bit around it, maybe 00:57:56.481 --> 00:58:06.107 let's jump into the BO model and maybe that explains what is done outside the handler classes 00:58:06.474 --> 00:58:09.262 So, if you create such an error... 00:58:10.194 --> 00:58:22.716 We already talked about the error categories. This needs to be stored somewhere. If I have like three errors for item 20 and two errors for item 10, there needs to be a place where we store those 00:58:22.597 --> 00:58:26.929 errors. And that is done in a new BO node, 00:58:26.821 --> 00:58:35.221 which is called... It's below the ROOT node, and it's called ERROR_HANDLER, right, Balazs? 00:58:34.921 --> 00:58:36.663 I think so, yeah. 00:58:35.648 --> 00:58:46.296 Maybe I just think a bit longer, and now, ah. Now I remember that it's called ERROR_HANDLING. 00:58:46.813 --> 00:58:54.354 After a deep thought. That's the error handling node. And this, in the end, it has as a main indicator, 00:58:54.565 --> 00:59:06.763 the error category. Because there's so much depending on the error category. I think we discussed that already quite a bit. This is stored in the error handling node. 00:59:06.968 --> 00:59:14.046 But not only that, also the wrong value. The value that has been set originally, 00:59:14.407 --> 00:59:23.973 or sent. Product_123 for example. That needs to be stored somewhere. This is stored in that ERROR_HANDLING node. 00:59:24.820 --> 00:59:32.127 Actually there are two values that we can store. That is for example, for the reference errors relevant, where we have 00:59:32.710 --> 00:59:35.071 the type code and the ID. 00:59:35.415 --> 00:59:49.019 That in the end identifies the reference error. And that's already it on that level, but you might ask yourself how do we know which item is affected. And that is a sub node of that ERROR_HANDLING node. 00:59:49.392 --> 00:59:59.739 So below the ERROR_HANDLING node, the thing long enough, the subnode is called ERROR_INSTANCES. There we have a pointer to the actual 00:59:59.781 --> 01:00:07.617 for example item keys. Why is that a sub node? The rational behind that is, 01:00:07.707 --> 01:00:14.077 that we think that have certain errors that affect many nodes. For example after there's wrong 01:00:14.582 --> 01:00:22.736 consignee, for example for ten items. I don't want to see that error ten times, but I want to see I have this error ten times. 01:00:22.706 --> 01:00:30.067 As one error, but they also resolve it in one go. That's why we decided that the error with an error category, 01:00:30.205 --> 01:00:40.000 plus the wrong value and additional wrong value for context. It's stored 01:00:40.415 --> 01:00:51.423 independent of the error instances. And the instances I mean we are in BOBF so we can just store the keys and the error category will know what is the node I take care about, 01:00:51.628 --> 01:01:00.130 because item product, it's route, party, route shipper, route consignees, I know the node from the category already. 01:01:00.605 --> 01:01:09.276 Then I just need to do a safety instance, the GUID of item 10, the GUID of item 20, etc. 01:01:10.478 --> 01:01:12.557 That's it, in the end. 01:01:12.948 --> 01:01:25.735 There's one more thing however, and for performance reason on the actual data node, like our item in that case there's also a field that indicated that this item for example has an error. 01:01:26.546 --> 01:01:33.162 So the field is called NODE_HAS_ERROR, so hmm, that's node an error. 01:01:33.739 --> 01:01:42.837 And as long as we have it on item level for example, it's at least one error 01:01:43.486 --> 01:01:52.277 instance pointing to that item. Then this node has error, that is true, x is not initial. 01:01:53.641 --> 01:02:01.861 That is why is that in the first place - performance. Because now if I'm in the after modify determination for such an item and no, OK. 01:02:02.415 --> 01:02:11.356 Something changed on the item and the item has an error, so maybe my problem is gone, so it notifies the... 01:02:11.699 --> 01:02:12.671 I'm on the item. 01:02:13.753 --> 01:02:22.040 I see I have an error and there's association technically from the item to the error instance node. 01:02:22.310 --> 01:02:36.407 Because it's all GUIDs and all BOBFs, it's pretty straight forward. So we, from the item we can easily navigate to the respective error handling node in the end. 01:02:37.952 --> 01:02:47.188 And from there, we have the error handler class, and then we say OK, error handler class can you please check if your problem is solved. 01:02:48.438 --> 01:03:03.394 As simple as that. And then we said we have five different errors on the item and maybe the user solved three of them, then three of the errors will be gone, but the other two will still remain, and instead with that also this NODE_HAS_ERROR flag remains. 01:03:04.458 --> 01:03:10.713 After the last error has been resolved then also this NODE_HAS_ERROR flag is also resolved. 01:03:11.477 --> 01:03:14.527 And then also if that is resolved 01:03:14.776 --> 01:03:26.681 the error handling class, error handling node is solved and disappears and with that the block disappears. All that is done in the end is after modified determinations. 01:03:26.860 --> 01:03:32.039 Yes, so we have after modified determination on the item, this then calls the 01:03:32.088 --> 01:03:44.448 action to say, or calls the error handler class to check if the error has been resolved. If the error has been resolved, then this error handling instances resolved, 01:03:44.442 --> 01:03:50.349 is deleted, if the error handling instance is deleted, the block 01:03:50.992 --> 01:03:56.292 is checked, if it's still an error instance there. And if not, the block is also deleted. 01:03:56.310 --> 01:04:09.253 All that's normal BOPF stuff. I think if you don't know what BOPF is, there are two episodes about that, that you may listen to, and then hear that again and you'll know what we are talking about. 01:04:09.777 --> 01:04:12.492 If I did not already lose you beforehand. 01:04:15.233 --> 01:04:20.112 That's in the end of modelling, so you have a node, an error 01:04:20.190 --> 01:04:30.766 that's also displayed on the UI as dot, and that's really small one, at least for us. So it's only the error category and the references, 01:04:30.953 --> 01:04:35.790 and the node so the item ??. 01:04:36.367 --> 01:04:47.339 Then, the actual that pointer to the instances, which is said error instance, and the flag in the actual data node, and the item, and the stop, and the route level, etc. 01:04:48.956 --> 01:04:56.779 And that's it. From the "BO" perspective, but that also means that coming back, closing the brackets, your question was: Can I 01:04:57.489 --> 01:05:04.861 listed advanced error, can I resolve or can I model any kind of error? 01:05:04.958 --> 01:05:13.112 At least if it's kind of cross node, then you have to think about how to, which node is marked with no test error in that case 01:05:13.184 --> 01:05:23.273 for example. How do i make sure that's removed correctly. That would be a challenge. If I have a 01:05:23.208 --> 01:05:31.788 combination of fields on different nodes, then the current concept I think would come to it's limitations, but if it's just a 01:05:32.468 --> 01:05:35.580 custom field on route level, custom field on 01:05:35.550 --> 01:05:49.226 item level, combination of fields on item level, I think that's all fine. Also the hierarchy is clear, that you say, the field on item level must match something on root level and, but the error is on item level, that's also fine. 01:05:49.936 --> 01:06:00.073 The only challenge is then if it's possible to change something on root level and that should also trigger reevaluation, that would be a bit tricky in that case. 01:06:00.554 --> 01:06:07.013 But for I think, there are many use cases where you are, lets say 01:06:07.549 --> 01:06:15.468 bound to one node and maybe a combination of fields on a node, but in the end you are on one node. 01:06:16.892 --> 01:06:19.602 Plus you have some context maybe from other nodes, 01:06:19.429 --> 01:06:32.636 that you have a combination of values of different fields and any change on any level can solve the error then maybe the error handling is not there yet. 01:06:35.112 --> 01:06:37.455 OK, but this means again, 01:06:37.516 --> 01:06:46.709 we have basically ann external caller who creates these instances so actual BO node instances in case there is an error, 01:06:46.746 --> 01:06:54.701 the BO is somehow self containing itself, meaning the BO detects if the error is solved, 01:06:54.966 --> 01:07:00.049 by calling or by asking so to say the individual error handler classes. 01:07:00.044 --> 01:07:06.924 Exactly that's a good point, the BO itself doesn't know if it's solved, it asks the handler classes if it's solved. That's a good point. 01:07:07.170 --> 01:07:17.752 And then once everything's solved to say that error instances are gone and then also the blocks are then removed again, and this is again done more or less by the business objected itself. 01:07:17.518 --> 01:07:27.463 Exactly, the error instances are gone, once the error instances are gone, the error handling node is grouping the instance is gone, and that is where other blocks are gone. 01:07:28.016 --> 01:07:32.793 That's the technical sequence, if i'm not wrong, right Balazs?. 01:07:31.693 --> 01:07:34.301 Yes that's correct. 01:07:34.211 --> 01:07:35.359 Thank you. 01:07:35.563 --> 01:07:45.177 OK. This feature is something which we, which we just have activated in standard or is it, is it something which you can call, 01:07:45.280 --> 01:07:52.779 which you control by the handler classes or how do you control this feature? 01:07:51.860 --> 01:07:55.964 Balazs, do you want to answer that or I take it? 01:07:55.664 --> 01:07:57.887 Yes, so there 01:07:57.845 --> 01:08:06.456 there's some criteria, so as you mentioned this is mostly the context of message processing and there's 01:08:06.282 --> 01:08:18.684 a limitation here, so this is active in the service which is called transportation order generic request 01:08:18.474 --> 01:08:22.085 or the TGI. 01:08:22.530 --> 01:08:31.802 Then in addition there's a customizing where you can enable the 01:08:32.084 --> 01:08:34.211 this error handling basically. 01:08:34.056 --> 01:08:42.648 Document type level, right? 01:08:43.887 --> 01:08:49.078 So it's available for Freight Orders and for Consignment Orders? 01:08:49.180 --> 01:08:54.540 Exactly, Freight Orders, Consignment Orders, Freight Units not yet, right? 01:08:54.426 --> 01:09:03.698 Maybe one more comment on the message as Balazs already mentioned is Transportation Order Generic Request In. 01:09:03.768 --> 01:09:13.616 I think there's one or two more prerequisites. One is that you have that replication indicator, I guess. 01:09:13.619 --> 01:09:19.718 So also if you're working with messages, will know better than I do what this means. Or if the, what's it called? A delta handling... Wrote it somewhere, wait a second. 01:09:26.918 --> 01:09:29.729 Complete Transmission Indicator, you mean. 01:09:29.561 --> 01:09:42.587 Ah, yes, now when you mentioned. If you're using this Complete Transmission Indicator only then it's active for the moment. Maybe we will widen the scope, that's lets say 01:09:42.685 --> 01:09:49.943 What we use for our 2020 course scenarios, consignment inbound message, freight order inbound message, and 01:09:51.014 --> 01:09:57.077 focus on that. It might be widened and we also think about 01:09:57.546 --> 01:10:06.980 message external users, but so far it's actually only was in a message, so let's say if we look at standard, it's only used only in the message handling so far, 01:10:07.112 --> 01:10:21.245 and for that specific message with that specific prerequisite, and if the customizing is active, that is of course compatibility consideration. We think it should always be active, 01:10:21.336 --> 01:10:35.462 and we also default it if I'm not wrong, for new document types, but of course if you just upgrade and don't care about that feature, you still want to see the errors in our forward error handing, because this is where you people are used to look for it. 01:10:35.991 --> 01:10:44.578 That's why you have to activate it in customizing explicitly, because it was a different behavior before and compatibility is key. 01:10:46.393 --> 01:10:59.240 So basically you control the behavior by other, the type customizing and currently only so to say quotes, activated for the Transportation Order Generic Request In. 01:10:59.631 --> 01:11:03.837 Which supports processes like the TOR Generic In, 01:11:04.282 --> 01:11:10.928 so the replication TOR Generic In, ASN, whatsoever, what's coming. 01:11:10.628 --> 01:11:17.706 Yes, I think, but that's another episode maybe. The Consignment Order might be something 01:11:17.629 --> 01:11:25.950 let's say, the very prominent user of that one, which is to be discussed in another episode, yes. 01:11:25.969 --> 01:11:39.159 That is ASN in the end typically end up being consignment on our side, Consignment Order and there is where we typically have that kind of master data errors and all scenarios. But of course also for Freight Orders. 01:11:39.381 --> 01:11:50.618 So you know i'm from consulting, so usually I also love to use these features in customer project, so is there any option to easily enhance it? 01:11:51.826 --> 01:11:58.298 So if I have a dedicated error, I want to do my own error category or so. 01:11:58.304 --> 01:12:05.749 Patrick you never get enough right? So ok. You said one in 50 error categories? Isn't that enough? 01:12:05.647 --> 01:12:13.512 Yes there's a chance to enhance that. Maybe Balazs you want to spend some words on what needs to be done? 01:12:13.561 --> 01:12:16.337 Yes I think if you... 01:12:16.037 --> 01:12:18.373 For greedy Patrick. 01:12:18.092 --> 01:12:30.518 If you've listened carefully until now and then you ask yourself how could you then create your own category I think you already have the answer. It's quite straightforward. 01:12:30.399 --> 01:12:34.556 So, yes it's possible. You can define your category. 01:12:34.857 --> 01:12:41.930 That's you already know, category has it's own handler class, which implements a certain interface. And then 01:12:41.966 --> 01:12:52.500 you have to implement this class and then there are a set of methods that you have to implement. You can also choose to implement from one of our 01:12:52.523 --> 01:12:56.771 standard super classes, for example if you just want to create a new like 01:12:57.247 --> 01:13:03.130 master data error, then you can inherit from the super class for the master data errors. 01:13:03.298 --> 01:13:15.737 Then you probably only need like a couple of lines of code to specify for which field you want to create this error category and so on. 01:13:16.331 --> 01:13:21.529 And then, once you have the category and it's handler, then there's a Badi, 01:13:22.184 --> 01:13:27.490 they can register it and add to the list of the available categories. 01:13:27.971 --> 01:13:38.006 And then you just need one last step. You also have to identify the situations as we mentioned. 01:13:38.343 --> 01:13:48.251 This is not done in the BO, but it's done outside. So there's a Badi doing the service processing. 01:13:48.348 --> 01:14:02.199 For the TGI service. And then it's possible to create an enhancement, a Badi implementation, where you detect this error situation and then you 01:14:02.470 --> 01:14:06.435 you write this error, that you've defined. 01:14:07.535 --> 01:14:08.538 Sounds easy, Patrick. 01:14:08.419 --> 01:14:22.311 More questions. Maybe we can mention some of the names. So first of all, the error categories. They are defined in the domain /SCMTMS/TOR_ERROR_CUT, 01:14:22.413 --> 01:14:29.065 I think it's the first step that Balazs mentioned, so you have to enhance that domain 01:14:28.993 --> 01:14:33.013 by your own Z category. 01:14:33.031 --> 01:14:40.026 It's a character ten, so that should be plenty space for meaningful cat. 01:14:40.309 --> 01:14:49.610 That's one thing. The interface that you have to implement, it's called 01:14:50.133 --> 01:14:58.917 /SCMTMS/IF_TOR_ERROR_HANDLE. 01:14:59.086 --> 01:15:01.636 That's the interface. 01:15:01.869 --> 01:15:13.521 And then we have the Badi. /SCMTMS/TOR_ERROR_HANDLING_CUT, where you do the mapping. As this error category belongs to the handler class. 01:15:13.612 --> 01:15:15.956 which then implements the interface that we just mentioned. 01:15:18.664 --> 01:15:31.349 And the last step is then this Badi where you rewrite error from the message and that's /SCMTMS/TOR_SE_TOR_GN_WRECK. 01:15:31.879 --> 01:15:37.893 And in there is specific message called DEPT_DATA_, uh, no. 01:15:38.680 --> 01:15:43.479 I lost my memory. Uh, yeah. 01:15:43.520 --> 01:15:54.420 TOR_GM_WRECK, that's the name. And then DEBT_DATA_FOR_OMUH. (For Auto Management Update Handler) That is where you then write the actual error. 01:15:56.653 --> 01:16:03.503 And the structure, which you write there is pretty much what we just described. 01:16:03.919 --> 01:16:11.754 The structure for the error handling. error handling class and the instances, you referring to. 01:16:12.380 --> 01:16:18.802 And if I would create an error category, let's say which is 01:16:19.440 --> 01:16:33.242 where there is a similar error category already in standard, so on the same node and so and then, I think everything would work more less out of the box. And if I would introduce a new node or if I would have an error on a node which doesn't 01:16:33.140 --> 01:16:38.597 have any errors on standard I would have to do some enhancements in the determinations and so on. 01:16:38.297 --> 01:16:53.127 Exactly. So you should follow that NODE_HAS_ERROR pattern however, you do have to implement after modified determination and the call yourself, but then you can just follow the pattern that we introduced in orgnization nodes that already have that error handlers. 01:16:54.996 --> 01:17:02.524 OK, cool. Sounds like a really nice concept and feature and has a bright future I think. 01:17:02.255 --> 01:17:11.635 Yeah, we hope so too. So we're talking what future may be. So some sorts that we have. Again we typically talk just so. 01:17:12.969 --> 01:17:27.577 What we talked about so far is mostly there. Subdivisions that we have here is that we also store more, because so far as mentioned, if an error is resolved it's really gone as it was never there. That of course is 01:17:27.769 --> 01:17:32.835 lean and uh data. 01:17:33.790 --> 01:17:43.404 Speaks German Oh das ist Datensparsamkeit Speaks German It's a lean usage of data for sure. However for some analytics, or even for 01:17:43.970 --> 01:17:57.063 improving solving errors for the future we think about storing more information on the error, and how it has been solved, maybe when it has been solved. By which means it has been solved. 01:17:56.907 --> 01:18:06.756 So for example an error that is typically resolved by retry after ten minutes maybe may even schedule something 01:18:07.243 --> 01:18:10.560 like ten minutes later. Awesome, yeah? 01:18:10.764 --> 01:18:22.019 To take example, that is one thing. We already talked about usages and planning like the mentioned geo and distance determination error, 01:18:22.283 --> 01:18:28.725 that is maybe a candidate. Maybe capacity check errors that we also make so small. Let's say explicit, 01:18:29.043 --> 01:18:32.769 explicitly handled. 01:18:34.050 --> 01:18:43.321 I also hope that has a bright future and that we can use it also for other scenarios we 01:18:43.880 --> 01:18:46.650 didn't even think of so far. So... 01:18:47.516 --> 01:19:01.522 But so far it turned out nice. Our colleagues from MIPSO, that was the artist formally knowns as custom development. We worked very closely with them on recent project. And they also already introduced their own error categories so. 01:19:01.462 --> 01:19:06.798 We know that's not only series that we described. And so, and... 01:19:07.033 --> 01:19:16.953 But that's only available with Feature Pack 1 or some nodes with full extendability. 01:19:17.591 --> 01:19:25.096 But yeah, I also think that's good feautre and can be, can solve problems and hope you did it well. 01:19:30.793 --> 01:19:37.300 OK, then it is a no more questions even from Patrick, that I think we... 01:19:37.000 --> 01:19:42.366 Everything is solved. Everything's solved, everything's answered. 01:19:42.066 --> 01:19:51.980 OK then, thanks a lot everybody. And we can call it an episode I would say. 01:19:52.311 --> 01:20:01.150 One hour, twenty minutes. That's solid episode, but it's okay. A lot of details. By the way, there will be... 01:20:01.289 --> 01:20:15.542 We are currenly preparing another podcast. I think I said that a year ago already right, so what were still preparing is a very deep preparation. Where we go a bit deeper, for example we now just mentioned are there different interface messages, etc. So we... 01:20:15.717 --> 01:20:22.687 As a podcast, TM Podcast, but Blacked Out Edition so it goes more into technology. 01:20:23.030 --> 01:20:30.432 We don't stay that much on the surface like today, but we go into some more details. 01:20:31.004 --> 01:20:38.605 Like the interfaces, etc. Interface messages required. And we also plan to have an episode on 01:20:39.122 --> 01:20:53.441 more deep, more detailed level, how to create such an error instance in this new podcast to come. But that's just a plan so far. It's not a promise, but a plan at least. 01:20:54.536 --> 01:21:08.056 And we hope to deliver that as well. And then if you liked this episode and now want to go and create you own error category, it might be worth listening to the other one. We will announce that on our usual channels. On SCN, that's linked in Transportation Management Group. 01:21:09.090 --> 01:21:17.633 And Twitter. TM Podcast - Twitter account, and then you would find us there. 01:21:18.277 --> 01:21:26.119 So thanks a lot everybody. Thanks for listening, thanks for asking, thanks for answering. And have a good day. Bye. 01:21:26.269 --> 01:21:27.560 Bye. 01:21:27.260 --> 01:21:30.626 Bye bye, thanks.