Sunday, July 31, 2011

Skype Integration with Dynamics AX

1. Application Area
Skype® is a popular utility for IP telephony. Skype Integration add-on integrates Skype with standard Dynamics AX (Axapta) in the same way, like phone integration is made in Dynamics AX (Axapta) CRM Telemarketing.
The functionality includes 2 main parts:
  • Everywhere in the application for all “phone” fields user has a possibility to make calls using standard Dynamics AX (Axapta) phone integration functionality (via TAPI) or by Skype.
  • It’s assumed that user is ready to receive inbound calls by phone and Skype.
Therefore, Skype-integration functionality provides an alternative way to make phone calls from Dynamics AX (Axapta), while standard Dynamics AX (Axapta) can do it (e.g. CRM Telemarketing) using usual modem and phone line only.

2. Prerequisites

Skype software is to be installed as client.
SkypeOut account is to be registered in order to make outbound calls to normal phones using Skype.

3. Workflow

3.1. Outbound call

Skype provides 2 ways of communication:
  • “Skype to Skype” using Skype account. Currently this service is free.
  • “Skype to Phone” using SkypeOut account. You must pay for such calls, but the cost is much lower than normal international phone calls (see

Skype to Skype calls

A new string field “Skype account” is implemented in relevant forms. At the moment, it is implemented in e.g. “CRM Contact Persons” table/forms, and located in the “Contact info” field group. When user presses lookup-button (an icon with image of phone), Dynamics AX (Axapta) makes a call to this Skype account using Skype software, installed on the client’s machine.
Skype to phone calls (using SkypeOut)
In this case, we already have usual phone number in standard ‘Phone’ field, and the only question is to decide, if we would like to call using standard Dynamics AX (Axapta) telemarketing functionality, or should we start the call via Skype? This is specified by a new parameter “CRM / Setup / CRM Parameters / [tab] Telemarketing / [field group] Skype integration/ [field] Outbound phone call”, which can have the following 3 values: Use telephone / Use Skype / Ask user.
In the first 2 cases appropriate interface is used without additional questions. In the third case, every time before placing a call, the user will see a dialog window, where he can specify if he would like to use Skype, or use standard way to place a call.

Figure 1: CRM Parameters
When user clicks a button to place a call using SkypeOut, the following steps are performed:
  •  Skype window pops up starting a call.
  • A new form “Skype call” is opened in Dynamics AX (Axapta). This form presents the information about current call, and looks similar to standard FRM smmPhoneDialog.

Figure 2: Call using SkypeOut
Dynamics AX (Axapta) form displays the following information:
  •  Telephone number or Skype account.
  •  Start time of call.
  •  Call duration.
  •  Contact information.
  •  Activity description. Functionality allows saving the call as activity, like it’s implemented in standard Dynamics AX (Axapta) telemarketing.
 The form allows to:
  •  Finish Skype call.
  •  Reinitiate Skype call.

3.2. Inbound call

When user receives inbound call, the following steps are performed:
  • Skype window pops up making a call.
  • Form described above is opened in Dynamics AX (Axapta) presenting information about current inbound call. (CRM/ Parameters/ CRM Parameters/ Employee options/ tab: Telephony/ field group: “Skype integration”/ field: “Activate answers” must be checked). At the moment, this feature does not work under Dynamics AX (Axapta) 3.0 SP3, but works under Dynamics AX (Axapta) 3.0 SP2.

4. Conclusion

Skype Integration is a useful add-on to reduce the costs of international calls for sales department of the company (if SkypeOut account is utilized), and add one more communication tool to Dynamics AX (Axapta) Telemarketing.

Source :

Thursday, July 14, 2011

X++ : lockWindowUpdate() vs. lock()/unlock()

There are two method pairs in X++, that are used throughout the application by everyone writing some processing on application forms. These are:




Now, not that many people know the difference between the two methods, and only very few think about why and when should each of them be used.
I will try to describe the behavior of these methods and at the end give some recommendations on how to use them. I have done some kernel code reading (with help of kernel dev. Andy Stach, who I would like to mention here), so what I write below is more or less backed up by code.
If you disagree with some of the recommendations though, please share your experience in using these methods through comments for this post.


is basically a wrapper around the LockWindowUpdate Win32 function. What it does is pretty simple:
When a window is locked, all attempt to draw into it or its children fail. Instead of drawing, the window manager remembers which parts of the window the application tried to draw into, and when the window is unlocked, those areas are invalidated so that the application gets another WM_PAINT message, thereby bringing the screen contents back in sync with what the application believed to be on the screen.
Note, that according to MSDN, it should not be used for general purpose suppression of redraw operations, but only when dealing with drag&drop operations. This does not hold true for AX, where this method is used all over the place to prevent redraw of controls on the form.
Another interesting point is that only one window can be locked at the same time. So, any nested calls tolockWindowUpdate will be ignored, but when unlocking, only the outer-most unlock will actually invoke the Win32 counterpart. Now, I have not seen this used in X++, which is for the better.


is internally invoking lockWindowUpdate to prevent the redraw of the window, and then also prevents the IntelliMorph control layout engine from running. This is commonly used in scenarios where control properties affecting control arrangement are being set in a loop, which provides a performance optimization as it avoids redundant arrange calls being processed. On the other hand, when calling FormRun.unlock, more work will need to be done, compared to usinglockWindowUpdate(false), where the control layout changes were actually processed by the layout engine, but simply not displayed.

So, based on my investigation, I would suggest to use the following recommendations when doing form development:

  • When formRun.resetSize() is used, specifically, when some controls become visible, increasing the form size, always use formRun.lock()/unlock(), otherwise the change in the size of the form might not get reflected on the screen correctly.
  • When changing multiple layout properties (Left, Width, etc.) on one or more controls, use lock/unlock
  • When you modify the properties that do not impact the layout of controls on the form, useformRun.lockWindowUpdate(), or, if there are only very few control properties being modified, do not lock the form window at all.