<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:large">Thanks Joseph for the response.</div><div class="gmail_default" style="font-size:large"><span style="font-size:small">>> I didn't see anyone else answer this.  Is your question about how to</span><br style="font-size:small"><span style="font-size:small">>> architect or design your D-Bus interfaces?  Is the reference the BMCWeb</span><br style="font-size:small"><span style="font-size:small">>> merely to provide context as a consumer of these D-Bus services?  I</span><br style="font-size:small"><span style="font-size:small">>> assume so.</span><br style="font-size:small">Question is two pronged, one we wanted to know the best way to propagate error from dbus to bmcweb.</div><div class="gmail_default" style=""><font size="4">Options we tried:</font></div><div class="gmail_default" style=""><font size="4">1. Have handlers of each property throw an exception if there was an error. But this did not work well with current bmcweb implementation(get all method call), as it would lead to the entire resource not getting populated even if we have one property failing.</font></div><div class="gmail_default" style=""><font size="4">2. Implement one additional associated rc property - and do the error handling bmcweb by looking at that, but this doubled up the number of properties on dbus.</font></div><div class="gmail_default" style=""><font size="4">3. Use "default values" per property data type, but this would fail for extreme cases like if the property is u32, and if the default value used was INT_MAX, then it breaks when the property could take value 0xFFFFFFFF as valid value.</font></div><div class="gmail_default" style=""><font size="4">So the query here was to check if any preference from above options or hear any new approaches as well.</font></div><div class="gmail_default" style=""><font size="4"><br></font></div><div class="gmail_default" style=""><font size="4">The second query was about how to represent this error(per property error) on redfish, our proposal for now is to return "NULL" for any property that might be failing at the backend. Any thoughts on this approach?</font></div><div class="gmail_default" style=""><font size="4"><br style=""></font><span style="font-size:small">>> I don't have any special insights.  Are you looking to follow a design</span><br style="font-size:small"><span style="font-size:small">>> pattern?  Are you looking for direction from the BMCWeb maintainers?</span><br></div><div class="gmail_default" style=""><span style="font-size:small"><br></span></div><div class="gmail_default" style="font-size:large">Yes, we are working on a design pattern proposal and will publish it here for review.</div><div class="gmail_default" style="font-size:large">It would be great if we could get some directions/inputs from the maintainers as well.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Thanks,</div><div class="gmail_default" style="font-size:large">Shakeeb</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 3, 2023 at 10:33 PM Joseph Reynolds <<a href="mailto:jrey@linux.ibm.com">jrey@linux.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/20/23 2:04 AM, chandu chanti wrote:<br>
> Hi Team, We are planning to handle errors from backend services in bmc <br>
> web. We are considering the following approaches to implement it, but <br>
> we are facing some issues. please provide your inputs. 1 . Using <br>
> exceptions in our backend D-Bus service<br>
> ZjQcmQRYFpfptBannerStart<br>
> This Message Is From an Untrusted Sender<br>
> You have not previously corresponded with this sender.<br>
> Report Suspicious<br>
> <<a href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJJyaRL1Nus7N26ProiLa90y_FB6oawxkmvrT4YcN373bBkdTP-XPRTFLRBygswzt1TwX0wxp5Tel83pR4ZZR-wpxEYJpcKudcTfq2FH6iPLN9Ep4cV_tX4$" rel="noreferrer" target="_blank">https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJJyaRL1Nus7N26ProiLa90y_FB6oawxkmvrT4YcN373bBkdTP-XPRTFLRBygswzt1TwX0wxp5Tel83pR4ZZR-wpxEYJpcKudcTfq2FH6iPLN9Ep4cV_tX4$</a>> <br>
><br>
> ZjQcmQRYFpfptBannerEnd<br>
><br>
> Hi Team,<br>
><br>
> We are planning to handle errors from backend services in bmc web. We <br>
> are considering the following approaches to implement it, but we are <br>
> facing some issues. please provide your inputs.<br>
><br>
<br>
<span class="gmail_default" style="font-size:large"></span>I didn't see anyone else answer this.  Is your question about how to <br>
architect or design your D-Bus interfaces?  Is the reference the BMCWeb <br>
merely to provide context as a consumer of these D-Bus services?  I <br>
assume so.<br>
<br>
I don't have any special insights.  Are you looking to follow a design <br>
pattern?  Are you looking for direction from the BMCWeb maintainers?<br>
<br>
Joseph<br>
<br>
> 1 . Using exceptions in our backend D-Bus service by throwing <br>
> exceptions in the D-Bus property get handlers. It works fine for the <br>
> Get property method call. However, when using the Get All method call, <br>
> if one property fails, an error is returned without checking the other <br>
> properties. Is there a way to implement exceptions in GetAll so that <br>
> even if one property fails, we can still fetch the remaining properties.<br>
><br>
> 2. Using default values in D-Bus properties to indicate errors. Is <br>
> there a reference implementation available for setting default values <br>
> for string and integer data types in bmc web, similar to the <br>
> implementation of NaN (default value) for the double data type in <br>
> cable.hpp.<br>
><br>
> 3. Implement associated return code per property on dbus, but this <br>
> would be very inefficient in terms of double the properties on dbus, <br>
> something we would like to avoid<br>
><br>
> Thanks<br>
> Chandrasekhar T.<br>
><br>
<br>
</blockquote></div></div>