Skip to main content

I've got something strange going on. I’m not sure if anyone is going to be able to help me, but I might as well try.

This is what I have in my 'Build String' block:

fn-Length({TextStart}{WorkflowVariable:strWVBasisValue}{TextEnd})

Publishing that workflow, everything is perfect, the grass is green, my workflow works, no problems.

But I have to publish this on 15 subsites and this is just one of 5 workflows. Luckily I’ve got a workflows that basicly publishes that workflow where-ever I tell it to. (I didn't write that workflow, my predecessor did) and from what I gather it creates an XML from the workflow in ‘textform’ (other options are to export to inner XML or outer XML) (I’m not an XML expert just yet, and I’m not a fan of altering this workflow because we’ve published hundreds of workflows like this with success). After getting all the info where it should publish the workflow it starts a webservicecall and calls the method ‘PublishFromNWFXml’ from the webservice at “site_url/_vti_bin/NintexWorkflow/Workflow.asmx”.

The product of that publish is that in the workflow my code in that ‘build string’ block is changed into “34” because “{WorkflowVariable:strWVBasisValue}” are exactly 34 characters. So instead of putting the formula in the ‘build string’ block, it executes it.

A solution to this was given to me in the form of ‘cut the inline function apart in little variables’ so my original function becomes:

{WorkflowVariable:FN-}{WorkflowVariable:length}{WorkflowVariable:openbracket}{TextStart}{WorkflowVariable:strWVBasisValue}{TextEnd}{WorkflowVariable:closebracket}

Publishing this the normal way results in everything working perfectly.

But if I publish this using the automated way the ‘build-string’ code is yet again altered. This time in the following:

{WorkflowVariable:FN-}{WorkflowVariable:Length}{WorkflowVariable:openbracket}e53e721f-4dd6-4248-ba44-3163054154fd{WorkflowVariable:closebracket}

If I remove the {TextStart}{TextEnd} parts even automatic publishing works, but then I can’t change any choices where special signs are used.

While typing this question I’ve learned a few things. Originally I thought that this service of automatic publishing workflows on numerous locations was a Nintex thing, and it is, given that it’s done using a WebServiceCall, but I had no idea we had some code behind it ourselves. So now I’m thinking, I should open up one of those XML files and see how it behaves there. However, I will not be able to debug that yet. XML is still, for a big part, a mystery to me.

It seems I still have some information to add before this question contains enough information. However, perhaps someone else stumbled upon a similar issue.

Hi Thorsten,

yes, other people stumbled as well wink.png There is already another thread open, about quite the same topic: PublishFromNWFXml Removes inline functions

Unfortunately noone could give any hint on the source of the problem yet. I'm using the "regular" web service call, without any custom code.

Philipp, 

Thanks for pointing that out for me. Believe me, it's an honest mistake. When I started looking for the solution here, I didn't yet know the name of the particular WebServiceCall (henceforth WSC) we were using. So I might have glanced passed it while browsing. As I've said, I've learned a lot while typing that message (I started typing it around 8 am, it took me hours between meetings before I could actually post it.


Well, we are in the middle of a migration from servers, and we're upgrading to Sharepoing and Nintex 2013, so starting tommorow I'll be testing non-stop. So this issue will be non-priority for the next couple of weeks. After that I'll see if I can find where the XML translation fails.


By the way, what regular WSC are you referring to? If there is another fail-safe approach to this, I'd be very interested in hearing about it.

By "regular" I meant the PublishFromNWFXml function, so the same function you are using. There maybe the possibility to provide your own web service method to publish a Nintex Workflow, but I never tried that.

So, I said I'd look into this, and I have. (Normally I'd be testing a migration, but our farm admins are still testing their end).

I've found a workaround, but it's quite complicated.

A number of terms are executed rather than placed in the 'build string' like we would expect it too. So that means that the xml-parser is acting up, and you need to find a way to circumvent that behavior. A way to do that is to disguise all keywords that would otherwise trip the parser. a few examples

  • fn-length / fn-substring / fn-toupper / ...basicly every in-line function...
  • (
  • )
  • {TextStart} / {TextEnd}

So I create a number of workflow-variables containing the following characters

  • fn-string: fn-
  • length-string: length
  • open-bracket-string: (
  • close-bracket-string: )
  • text-string: {Text
  • end-string: End}
  • start-string: Start}
  • sub-string: substring
  • ...

so a simple formula:

fn-substring({TextStart}somestring{TextEnd},2,2)

becomes

{WorkflowVariable:fn-string}{WorkflowVariable:sub-string}{WorkflowVariable:open-bracket-string}{WorkflowVariable:text-string}{WorkflowVariable:start-string}somestring{WorkflowVariable:text-string}{WorkflowVariable:end-string},2,2{WorkflowVariable:close-bracket-string}

Effectively fooling the parser to work as expected. Not sure if it's the Query XML parser that is doing the tripping, or the WSC, I TRIED reading the XML file, but I couldn't make much of it.

I'm going to flag this as solved, although, I suspect someone from Nintex is going to want to take a look at this themselves.

At least it's some workaround at all. Thank you very much for sharing this information!

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings