Skip to Content

Forms Session

One of the difficulties when dealing with SAP B1 is the “stateless” condition that object have between events fired on the UI.

If one creates a class that handles the events for a given form then just creating a simple static variable would solve the “stateless” problem, but when you wish to have more then one instance of the form then this approach does not work.

To work around this I came up with the class below, which uses the FormUID (the unique identifier of the form) to identify the object that belongs to it. Meaning that you create your object and store it by using the FormUID as the key.

When an event gets fired you simply ask the FormsSession object to return you the object stored for the FormUID. This takes care of both problems, the “stateless” condition and the single class object.

One thing not to forget is to remove the object from the Session when the form closes (or like I intent to do, improve this class to auto-register to the close event and remove the stored object automatically).

public class FormsSession<T> where T : class, new()
 {
 private static Dictionary<string, T> _container = new Dictionary<string, T>();
 public void Add(string FormUID, T FormObject)
 {
 if (_container.ContainsKey(FormUID))
 _container[FormUID] = FormObject;
 else
 _container.Add(FormUID, FormObject);
 }
 public T Get(string FormUID)
 {
 if (!_container.ContainsKey(FormUID))
 _container.Add(FormUID, new T());
 return _container[FormUID];
 }
 public void Remove(string FormUID)
 {
 if (_container.ContainsKey(FormUID))
 _container.Remove(FormUID);
 }
}

Comments and critics are welcome.

Best regards,

Pedro Magueija

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Edy Simon

    Hi Pedro,

    What kind of object do you need to keep in between the ui events?

    IMHO, we should keep all our data in the form itself.

    Reason being, if we keep the data in our running .net object, when the add on stop for whatever reason

    We cannot just simply restart add on and continue. We need to close and reopen the form or at least reload the object.

    For the same reason, I found that b1studio for vs2010 is not suitable, well at least for me.

    It keeps too much object in memory. When the addon crash, all the form needs reopening.

    Or maybe I haven’t found any need to keep this object.. ๐Ÿ™‚

    Maybe you can enlighten me..

    Cheers,

    Edy

    (0) 
    1. Former Member Post author

      Hi Edy,

      The object I am speaking of is a domain object. For example, if we have an object which represents a person this object will have behavior associated with it. But the data on the form will not. Every time an event is fired you will have to take the data process it, and set it on the form.

      A simple sample would be if you have a birthday and age displayed on screen, you will have to catch the validate on the birthday check if it is valid, calculate the age and set the age. In this case, if you do it in the form event handler logic is being coupled with the UI which is not good. So one should move this “behavior” to the domain within the object Person.

      The problem I had is that between calls the object Person is not maintained. So I needed to come up with a “container” to put the object in and be able to refer to it (also taking into consideration multiple form instances).

      This was one (meanwhile I’ve seen many different implementation which also allow for the object being persisted between calls) of the solutions.

      Another thing this approach will also provide is, if you need to do something with the object (like pass it to another method to be sent somewhere, changed and re-displayed), the behavior will stay intact and the “other” application does not have to implement the same logic that your event handler is implementing, because it is in the object Person.

      Please note that having the data on an object, does not mean you won’t have it in the form’s datasources. It just means that the primary source of data is the object and not the datasource.

      I agree when you say a disadvantage is if a crash happens the object having to be reloaded. But on this matter there are mechanisms we can create to recover the object after a crash.

      This “approach” is also not to be seen as a “silver bullet”, instead it is one more way to have an object bound to a form.

      I hope I haven’t made things even more confuse.

      If you need any more info, please leave me a line.


      Best regards,

      Pedro Magueija

      View Pedro Magueija's profile on LinkedIn

      (0) 
      1. Edy Simon

        Hi Pedro,

        Thanks for explaining. It is crystal clear.. ๐Ÿ™‚

        The object you are referring to is a complex object which can even consists of its own logic.

        Now I remember that I did pondered about going this way once. I ended up leaving all the data in the form, and when the object is needed, I would always re-read the data and re-init my object.

        Come to think about it, just cross my mind,  we can actually save an XML string as a Memo UDS.

        And make our Object initialize from this XML string… ๐Ÿ˜› .

        Well, definitely there are plus and minus.

        Great to see it from other’s perspective and try adopting it to improve me.

        Regards

        Edy

        (0) 

Leave a Reply