Unsere Kunden wollten, dass deren Belege (Angebot, Lieferschein, …) in unterschiedlichen Sprachen gedruckt werden können. Die Sprache sollte von außen, dem Modul (Angebot, Lieferschein, …), vorgegeben werden. Unser Ziel war, möglichst nur einen Beleg pro Modul zu verwenden.

Lösung

Wir haben die Funktion “lookup” verwendet.  Die Funktion ist als Ausdruck/Expression “=lookup(“invoice.Artikelnummer”, Fields!rep_key.Value, Fields!rep_label.Value, “DS_Localization”)” in einem Textfeld eingebunden. Damit die Funktion den richtigen Wert liefert muss auf der Datenbank eine Übersetzungstabelle vorhanden sein. Diese Tabelle muss anschließend als DataSet im Bericht eingebunden sein. Im DataSet wird anhand der Where-Bedingung die Sprache selektiert. Diese muss demnach als Parameter mit übergeben werden.

In diesem Fall liefert der “lookup” die Übersetzung dür das Feld “invoice.Artikelnummer” zurück. Die Felder “rep_key” und “rep_label” kommen aus der eingebundenen Tabelle (DataSet “DS_Localization”)

Tabelle

rep_key (Schlüssel)
rep_label (Bezeichnung; Text der gedruckt wird)
rep_local (Sprachschlüssel; EN, DE, FR, …)

Was aber oft nicht bedacht wird, ist, das es in Deutschland bei einigen Banken (z.B. Commerzbaank, Deutsche Bank, …) sogennante Hauptkonten gibt. Diese Hauptkonten enden mit einer doppel Null “00″. Hat aber nichts mit dem “Geheimdienst Ihrer Majestät” zu tun. Das Hauptkonto kann bei einer Transaktion mit oder ohne “00″ angesprochen werden. Bei der Ermittlung einer richtigen IBAN kommt aber als Prüfziffer der gleiche Wert raus. Also das Konto 7896543 und 789654300 liefert die gleiche Prüfziffer. Aber nur wenn die Ermittlung über eine Bank läuft. Wird die Ermittlung über ein eigenes Programm gesteuert werden für beide Konten unterschiedliche Prüfziffern gebildet. Das ist zwar mathematisch richtig aber in diesem Fall logisch falsch. Eine 100% Lösung bei der Berechnung gibt es nicht.

Viel Erfolg bei einer SEPA Umstellung.

Its not that clear that the issue is on the client side. So troubleshooting on the UAG-side did not help. Further research and testing revealed the culprit. Microsoft!

After a certain Hotfix, KB2592687 to be precise, the connectivity issues started.

So I did a quick

Get-Hotfix -Id KB2592687

to see if I had the patch installed. And yes it was. So another

cmd.exe /c wusa.exe /uninstall /KB:KB2592687 /quiet

and a lot of waiting and restarting finally allowed a connection via RDP via UAG.
A hotfix for the UAG to allow newer RDP clients is still not available!

This projects requires the use of .Net 3.5 which makes it impossible to use NEST as elasticsearch client.

To at least add a little bit of comfort when writing the queries against the search-cluster I make use of RestSharp for easy connecting and JSON handling. Net 3.5 has no ExpandoObject to create dynamic property names. It took me awhile to find out but a simple Dictionary does the trick.

var innerQueries = new List<object>();
 
// Data is a Dictionar<string, string> where the key is the fieldname used in elasticsearch
// and the value the value to search for (e.g. title => foo; description => baz)
foreach(var token in data.Keys)
{
  dataResult.Add(new
  {
    match_phrase = new Dictionary<string, string>;
    {
      { 
        token,
        data[token]
      }
    }
  });
}
 
var final = new
{
  query = new
  {
    @bool = new
    {
      must = innerQueries
    }
  },
  from = 0,
  size = 250
};

Serializing this into JSON and sending it via RestSharp creates a request with multiple must “clauses” each using a match_prase query.

{
  "query":{
    "bool":{
      "must":[
        {
          "match_phrase":{
            "record.title":"foo"
          }
        },
        {
          "match_phrase":{
            "record.description":"baz"
          }
        }
      ]
    }
  },
  "from":0,
  "size":250
}

SharePoint Workspace was unable to interpret the SharePoint location.
Please check and ensure the location contains no typing errors.

Of course this error message is misleading. Solutions found in “the internet” like adding “remote differential compression on the server” were not applicable…

So after further tracing I found the culprit. The ULS logs (verbose mode was configured for logging) showed the exact web service calls SharePoint Workspace 2010 did with its full soap body. One call showed an url which I was pretty sure was not inside the AAM of that specific web application. Other calls always show the correct public url of that web application. Just one specific call … So I added it to the configuration and everything is working and synchronizing as expected.

If you encounter this error check your ULS logs and double check your AAM settings!

After inserting a record into the grid via RowEditing and pressing cancel the RowEditings’ editor window is not shown. You guess it right: only when using Internet Explorer (7, 8, 9). After testing it showed that the css itself is not the reason. So debugging the Extjs-source where the setting scopeResetCSS is evaluated…

The final result is a workaround applied via Ext.override to solve the “problem”.

if(Ext.isIE) {
  Ext.AbstractComponent.override({
    onRender: function(container, position) {
      var me = this,
        el = me.el,
        styles = me.initStyles(),
        renderTpl, renderData, i;
 
      position = me.getInsertPosition(position);
 
      if(!el) {
        if(position) {
          el = Ext.DomHelper.insertBefore(position, me.getElConfig(), true);
        }
        else {
          el = Ext.DomHelper.append(container, me.getElConfig(), true);
        }
      }
      else if(me.allowDomMove !== false) {
        if(position) {
          container.dom.insertBefore(el.dom, position);
        } else {
          container.dom.appendChild(el.dom);
        }
      }
 
      if(Ext.scopeResetCSS && !me.ownerCt) {
 
        if(el.dom == Ext.getBody().dom) {
          el.parent().addCls(Ext.baseCSSPrefix + 'reset');
        }
        else {
          if(me.$className != 'Ext.grid.RowEditor') {
            me.resetEl = el.wrap({
              cls: Ext.baseCSSPrefix + 'reset'
            });
          }
        }
      }
 
      me.setUI(me.ui);
 
      el.addCls(me.initCls());
      el.setStyle(styles);
      me.el = el;
 
      me.initFrame();
 
      renderTpl = me.initRenderTpl();
      if(renderTpl) {
        renderData = me.initRenderData();
        renderTpl.append(me.getTargetEl(), renderData);
      }
 
      me.applyRenderSelectors();
 
      me.rendered = true;
    }
  });
}

The woraround itself is only this:

if(me.$className != 'Ext.grid.RowEditor') {
  me.resetEl = el.wrap({
    cls: Ext.baseCSSPrefix + 'reset'
  });
}

BTW: I “love” IE!

Simply using unsetChild and simply put the top.links block somewhere else is not working! All default links except the Log in / Log out disappear.

So here is my solution that works. The key is using insert as action…

<?xml version="1.0" encoding="UTF-8"?>
<layout>
  <default>
 
    <reference name="header">
      <remove name="top.search" />
      <action method="unsetChild">
        <alias>topLinks</alias>
      </action>
    </reference>
 
    <reference name="right">
      <action method="insert">
        <blockName>top.links</blockName>
      </action>
    </reference>
  </default>
</layout>

Note: Its important to use the alias when defining action="unsetChild" or the block is not “moving”. Seems buggy to me …

Trying the suggested solution in the blog post drove me to the cause of this problem. When using stsadm I got an “access denied” error.
I did run my script via Powershell ISE within Windows Server 2008.

So the real problem is caused, again, by UAC (User Account Control). When starting the Powershell ISE with “Run as administrator” and executing the script the feature receiver is now called as expected. Even when using Enable-SPFeature!

In case you quickly want to test if your SPSiteDataQuery is correct you can use powershell to “debug” it. Just create an instance of the site-collection and target the root-web with your query-instance.

$site = Get-SPSite -Identity http://my-site-collection
 
$q = New-Object -typeName Microsoft.SharePoint.SPSiteDataQuery
$q.Query = "<Where><And><Eq><FieldRef Name='ContentType'/><Value Type='Text'>MyCT</Value></Eq><BeginsWith><FieldRef Name='Url'/><Value Type='URL'>/path</Value></BeginsWith></And></Where>"
$q.ViewFields = "<FieldRef Name='ID'/><FieldRef Name='ContentType'/>"
$q.Webs = "<Webs Scope='SiteCollection' />"
 
$site.RootWeb.GetSiteData($q)

This is way faster than doing it in VS…