Ah.. I did not realise the order was important.

after switching and loading jQuery first, and jQM later - it worked.

Thanks.

Steve

This hasn't made a difference Stefan.

Hi,

I removed jquery-1.10.2.min.js and left jquery-1.11.3.min.js.  however, the problem still exists. 

Steve

Great.  Thanks for clarifying Mark.

Hi Mark, just on the ECP comment, I thought the ECP clients would define their ECP server using the VIP of the mirror set.

Can you explain here how you would you configure the ECP clients without a VIP address for the mirror set?

Thanks

Steve

This is a good idea.

But once again, though, the core question was whether MDX afforded me syntax, that would show only the latest RelocationDates for distinct CitizenRef's found.

(so - assume, my source table only has ID, CitizenRef, RelocationDate, City and Surname fields, and cannot be modified).

Thanks for the suggestion though.

Steve

Thanks, but in my question, when asking if "there is another (more elegant ?) way of achieving the same result without creating a the dimension ‘IsLastKnownRecord’ in the cube, but instead, directly as part of the pivot table."

I meant, is there a way of achiving the filtered results showing the last recorded date, using, only MDX syntax - (and not creating a dimension derived from the underlying source data).

Your solution assumes I have access to the source class and data model. If I do, then yes, i'll extend the underlying source data model in one of several ways (including that mentioned in a subsequent post).

Note also - that I still want to quert all logged events so setting a cube buildRestriction is not something I would be wanting to do.

thanks anyway,

Steve

Hi,

I have run some tests in order to answer my own question on this thread, and that is - what are the licensing implications of using SOAPSESSION for web services hosted within Ensemble (E-type). I thought its worth posting the answer here for completeness.

Given that Ensemble E-Type licenses do not consume license units, there are no license implications that I can see.  Sure the CSP Session hangs around for the duration of the SOAPSESSION calls until the user decides to end it, but, the license count (seperate from the CSP Sessions) is not effected and remains unchanged.

Thsi is not true for Cache or Ensemble C-type licenses. With the license unit consumed at the begining of the SOAP session, and, with the session on the back-end persisting for all subsequent SOAP Service calls from the web client, until the session expires, or is programatically ended - one needs to be aware that the license unit remains in use for this whole period.  

It becomes critical that SOAP applications that that implement SOAPSESSIONS make sure their session are correctly terminated with the back-end when  it is no longer needed, otherwise, the license unit will remain in use for, at least,  the session timeout number of seconds defined against the web application.

Steve

This is correct, and I have been testing this.

Ensemble E-type licenses do not count license units for SOAP service calls into Ensemble. This is true regardless of wether the user is identified, un-identified, or, SOAPSESSION is in play.

With Cache or Ensemble C-type licenses, License units are counted, and additionally, if anonymouse identity is used, a minimum 10 second grace period must be consumed for the connection regardless. 

Thanks - Steve

Good question re multiple SOAP requests in parallel.(ie - 2 simultaneouse SOAP requests that have the same CSPCHD soap header identifying the same SOAP Session, send simulateously to the web service).  

I have tested this. I sent two SOAP-Session enabled web service requests to the same web service and method, exactly 5 seconds apart. They both used the same session ID in the soap message.  The SOAP Service hung for 30 seconds, then, returned the server time.

The responses messages where received, one after the other, in the order they where sent, and 5 seconds apart, so it seems that they are queued FIFO.

Steve

Thanks Stefan.

I had read that, and understand how with SOAPSESSIONs enabled, soap calls can utilise the same session on the back-end.  My tests definitely show this working.

What I was hoping to discover however, is if license unit consumption is effected or not effected, with the SOAPSESSION=1 model, which is what is implied by the comment against the parameter which says ".Also effects license consumption".

My tests show that license unit consumption for SOAP requests that are session based are no different to others - so - I still can't see that there are an license unit consumption implications.

In fact - it seems that no SOAP calls seem to be consuming licenses in the scenarios I have tested described below when using SOAP UI from an different IP address to the web service server...:

(a) with and without SOAPSESSION=1 set (and where set, CSP header is used by the web client)

(b) with or without Unauthenticated or Password access set on the CSP Application.

(c) with a hang of,say, 10 seconds in the web method (allows me to gather license counts).

(d) web service hosted as a standalone Cache web service, or, as a webservice that's part of a Business Service in a running Ensemble production (csp Gateway used for access).

In all scenarios and combinations of each above, it seems, no license units are consumed at all.  I would have expected that (at least for SOAPSESSIONs enabled) a license unit would have been consumed for the duration of the session.  My tests do not confirm this, hence the question on trying to clarify what the license implication actually are.. :)

Perhaps a broader understanding of how SOAP requests consume and then release license units is a better approach to addressing this thread.

(Note that my license key does not have the Web-Add option enabled. This is 2015.1.)

Steve