Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Things should work as expected during the craftsmanship of a solution, but sometimes you have to face an ‘inconvenience’ which doesn’t sound logically to do. This post dives into such a feature which passed by during my own AppWorks journey. It’s an interesting one, and I just need to share it with you. This way you don’t need to ask yourself why?, how?, when?, what? on this particular feature.

Let get right into it…

Just prototype yourself a nice entity with name nil 🤔 and add some fancy properties to it. It doesn’t matter what you add, as long as you also add the ‘Web service’ building block. Make sure to expose the ‘Read’ and ‘Update operations on it (Think “MVP”!) and save it nicely in the ‘entities’ folder.

Publish it all and create your first “prototyped” instance in runtime.

The exposure of the service operations need to be supported by a brand-new ‘Application server’ connector. This is a thing to be created from the ‘System Resource Manager’ within the organization. Make sure to add the correct method set (from our entity) as interface, so our platform ‘knows’ who is responsible to manage the exposed service calls.

If you still don’t know how? Have a search for plenty of examples or comment me to provide you with the correct information.

Time to open the ‘Web Service Interface Explorer’ artifact, have a search for our exposed webservice, and do a first ‘Read’ test (with valid response!):

Nice…Next is the “update” request

The “Updatenil” call

Again, in the ‘Web Service Interface Explorer’ artifact we make a call to the ‘Updatenil’ webservice like this:

1
2
3
4
5
6
7
8
9
10
11
12
13

<SOAP:Envelope>
  <SOAP:Body>
    <Updatenil>
      <ns0:nil-id>
        <ns0:ItemId>080027e84f06a1ec94d4f5da869ba994.1</ns0:ItemId>
      </ns0:nil-id>
      <ns0:nil-update>
        <ns0:nil_name />
        <ns0:nil_summary>new summary</ns0:nil_summary>
      </ns0:nil-update>
    </Updatenil>
  </SOAP:Body>
</SOAP:Envelope>

The response gives us the following information:

1
2
3
4
5
6
7
8

<wstxns2:nil>
    <nil-id>
    <Id>1</Id>
    <ItemId>080027e84f06a1ec94d4f5da869ba994.1</ItemId>
    </nil-id>
    <nil_name>test001</nil_name>
    <nil_summary>new summary</nil_summary>
</wstxns2:nil>

Works as expected with an interesting ‘smell’ as the nil_name is untouched although the request sends out an empty element!? So, a valid question would be: How to make the value empty!? Well, that’s where the power of “nil” will help us!

Watch this update in the call:

1
2
3
4
5
6
7
8
9
10
11
12
13

<SOAP:Envelope>
  <SOAP:Body>
    <Updatenil>
      <ns0:nil-id>
        <ns0:ItemId>080027e84f06a1ec94d4f5da869ba994.1</ns0:ItemId>
      </ns0:nil-id>
      <ns0:nil-update>
        <ns0:nil_name xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" />
        <ns0:nil_summary>new summary</ns0:nil_summary>
      </ns0:nil-update>
    </Updatenil>
  </SOAP:Body>
</SOAP:Envelope>

NICEEE…That’s exactly what I wanted to see, and this also fixed an issue I faced during my own journey. ✌

That’s all folks…an easily “DONE”, and now you also know how to make a webservice call where we pass an ‘empty’ value as part of the message. Simple, and efficient, but with a strange smell you just need to get familiar with. Have a great week-end…Cheers! 🍻

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?