Working with reference lists in canned workflows - ocean

I am experimenting with canned workflows and need to know if it's possible to work with lists of domain objects in a reference variable, i.e. reference lists. Here is some code to illustrate the concept...
public void Run(Workflow workflow)
{
ReferenceVariable variable = workflow.InputReferenceVariables.First();
WorkflowRunner runner = new WorkflowRunner(workflow);
List<PointSet> pointSets = PetrelProject.Inputs.Selected.OfType<PointSet>().ToList();
runner.SetInputVariableBinding(variable, pointSets);
runner.Run();
}
This following picture shows the basic workflow.
"Local reference variable 1" is the input variable to which I am assigning the reference list. I know the example is hacky, but I tried to simplify everything as much as possible.
Anyways, it doesn't seem to work by binding a list, but it also doesn't throw any exceptions. Nothing happens at all when I run it. Anyone have any ideas?

Official response from Schlumberger is that reference lists are not yet supported. There is a work item in their system to provide a reference list API, but it is not yet target for a release.

Related

AbilitySystemComp GetSet retrun null

I have been implementing GAS in a project of mine and something is bugging me to no end.
In this youtube video made by unreal, they use the function
AttributeSet = AbilitySystemComponent->GetSet<UGASAbilityDemoAttributeSet>();
Where according to the video and the doc, GetSet is supposed to return the set if it exists or creates it and then give the newly created set. However, when I use it, it always returns null and I can't find a difference in my implementation.
What is it that I am doing wrong?
Other Sources
In the docs, they also mention to do the same.
I also downloaded and look at the implementation for the new Lyra demo project where it's a lot more complex, but in the end, they, themself, do the same.
Note
I know I can just
MySet = CreateDefaultSubObject<UGASAbilityDemoAttributeSet>("My Set")
To create my set, but the fact that I'm unable to use it like they do bug me.
I had the same issue. I found out that you have to first set the "Default Starting Data" on you Ability System Component in the editor. After that the GetSet method returns an object.
screenshot

How to differentiate if a TBO is called when importing new Document vs for any other operations

We are trying to add one additional feature to our method for TBO. The feature needs to be executed only when a new document for that object type is imported and should not be executed in any other case like checkin checkout or any changes in attributes.
However the new code is getting called everytime we make any changes to attribute to that document.
We have put that code in doSave() method.
I tried isNew method for distinguish between newly imported Document and other scenarios, however could not get success, may be missing the usage details of the method.
Can anyone suggest anything?
We are on Documentum version 7.2.
I always use isNew() method to check is object new or versioned, I don't remember having problems with it at any DFC version.
Only one thing that comes in mind is to make sure you don't use super.doSave() while inside the code since right after it method will return false.
But this is expected behaviour.
If you really need to do this - some calulations based on programatically preset data - make sure you use value saved within local variable throughout your code.
If you think you are experiencing bug with the method try with another DFC version or report a bug to the Support.

Another doGet() issue with Google Apps Script - "Unknown macro doGet" error

I'am obviously new to Google Apps Script, nevertheless I have some experience in coding in C, PHP and Java. Since we would like to create a small CRM in our company with Google Apps Script, we need to create an application with a form available on Google Sites. I've been searching an answer for this problem a long time, I haven't unfortunately found any answer. I have a code like this:
var klienci_id = new Array(100);
var klienci_nazwa = new Array(100);
var klienci_adres = new Array(100);
var klienci_osoba = new Array(100);
var klienci_telefon = new Array(100);
var klienci_email = new Array(100);
function doGet(e) {
var app = UiApp.createApplication();
// hello world label
var helloworldLabel = app.createLabel("I love Apps Script!").setStyleAttribute("fontSize","16px");
// add the label to the app container
app.add(helloworldLabel);
return app;
}
function main() {
var klienci = SpreadsheetApp.openById("0ArsOaWajjzv9dEdGTUZCWFc1NnFva05uWkxETVF6Q0E");
var kuchnia_polska = klienci.getSheetByName("Kuchnia polska");
var dane = kuchnia_polska.getRange("D7:F22");
doGet();
}
And everytime I try to publish it and enter the given link I get the error "Unknown macro doGet". I know this is a common problem when somebody doesn't use doGet() function but I do - and it still doesn't work. I also believe that Google should create a thorought documentation on Google Apps Script, which would work the way the Unix manual does, since I just cannot get through all these strange pages of goddamn help :) It's neither a Windows help, nor a good manual ;)
Regards,
Kamil
I have a suspicion that you made a "version" once, published the app, went to the "real" link and not the "development" link, and then added the doGet() function. When you make a version, it freezes the code at that time. The version that the app is published at is the version of the code that will run at the "real" link (what you give users), which allows you to keep editing the code without disturbing existing users of your app. There is a special "development" link given to you in the publish dialog that always refers to the most recent version of the code, but which will only work for you and no one else.
I'm affraid there is a little misunderstanding on your side concerning the use of the 'doGet()' function. When you want to run an application as a webapp, the doc says indeed that it must contain a doGet function but what it doesn't say explicitely is that this function is supposed to be the starting point of the whole app, ie the function that the url will call in the first place. So it doesn't make much sense to have the doGet function called from a so called "main" function since the "main" function is not the main function...
I cannot imagine right now a situation where some function calls the doGet function since every function in the script is called initially (directly or indirectly) from this doGet function.... in fact the 'end' of any other function in the script 'returns' to the doGet initial function. Well this is maybe not absolutely true in every case but it gives you the general idea about how it works.
I'm hoping this is clear enough and, to return to your code snippet, if you remove the doGet(e) call, it will ideed show a nice "I love Apps Script!" but it will never do anything else, certainly not see the "main" function.
I've copied your code here https://script.google.com/macros/d/MJ80AK8t7kbgDcC-NaLPYvH797_hv7HHb/edit?template=app&folder=0AKGkLMU9sHmLUk9PVA
and when deployed as a web app appears to work https://script.google.com/macros/s/AKfycbxOiaukLt7P4pIm7bms7aU16uEo6FuZ-MNOh0tSqUwr/dev
Only thing I can think of is there is something else in your code not copied into the snippet that is throwing the exception.
[Just before the GUI Builder was published I came up with Creating a framework for custom form interfaces using Google Apps Script which might help you with your project]
Thank you both for help. Serge, yes, it's really not obvious what the structure of Google Apps Scripts should be. They are based on JavaScript, however, due to lack of HTML in the code they have completely different flow - so naturally, there has to be a main function which is executed first. And of course in every programming environment it has to have a different name to make it more distinguishable ;-)
I created a new copy of my application, not changing the code completely - deployed it and it works beautifuly. Since I haven't changed anything in access options, it's quite strange that two applications with the same code and the same options don't give the same result. I think it may be a kind of the environment flaw, maybe someone from Google should look at this :)
Here's the link to the script, I've set access to "Anyone with the link".
https://script.google.com/a/macros/foodbroker.pl/s/AKfycbwk2IM-rIYLhQl6HOlbppwGOnw4Ik_kH7ixbaSNVxIE-QR7cq8/exec

LINQPad Dump() method not working for Sharepoint Client Object Model

I'm using LINQPad (2.42) to test some snippets that make use of SharePoint Client Object Model.
Basically messing with SPSite, SPWeb, SPList, SPFolder and SPFile.
The problem is that LINQPad seems to dislike calling .Dump() for any of the previous objects. It just keeps "Executing" for ever without showing any results.
Does anyone experience the same problem? Any workaround or fix?
Thanks
Try calling .Dump(0) to only dump the first level of Properties, or dumping the results to a Grid.
I have not looked at the SharePoint Client Objects but if they are anything like the TFS API classes, some of the properties are lazy loaded. Calling .Dump() will walk it's way down each every single result making server calls for every property (and property of property, etc.). This is probably what's taking the time.

Item is not added into the list (from code)

We have some strange problem here. We have feature event receiver, where we are creating custom fields -> content type -> list. After that, one default item is added. On my VM it was working just fine, but after moving into pre-prod environment, we got this strange behavior with no exception or error in logs.
First thing, item was created only sometimes, with no trace what happened. Mostly it was not created. I even experienced this: when I activated feature, I went to the list and so item there, but after refresh it was gone!
We tried to put there some Thread.Sleep() cycle (while debugging, item was in Items collection, but ItemsCount property of the list was always showing 0).
Now I am out of ideas what is wrong. It's not about execution time (maybe). Looks like, for some reason, SP is killing SPItem.Update before it is created for real and we don't know why. Any help is really welcome!
When you try to access sharepoint items from code and not have admin permissions to update/ delete them then set website website.AllowUnsafeUpdates = true; property
//Set AllowUnsafeUpdates = true to update the database / sharepoint list from code.
FormWeb.AllowUnsafeUpdates = true;
NewItem.Update();
FormWeb.AllowUnsafeUpdates = false;
you code should be like this to make changes in the list.. when you adding item to list.
Use Update statement in same manner when you accessing list and updating its data.
Check whether you updating the list correctly.. There may be some SharePoint security issue.
Reference Link:
http://blogs.msdn.com/b/infopath/archive/2010/04/01/add-items-to-a-sharepoint-list-using-managed-code.aspx.
You can check this [SPSecurity.RunWithElevatedPrivileges][1]
[1]: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx , link, link
you can check that what is going over there by adding your events in sharepoint..
Check this post and debug it..
http://developmentsolutionsjunction.blogspot.com/2011/06/adding-events-and-eventhandlers-in.html
so I was finally able to find out where the problem was. After deeper study and trying that and this I found out that there was a third party feature. It was adding event to each created list and was deleting everything what wasn't consistent with CT defined by company. This is weird and I don't really understand why somebody wants this. But ok, they pay, their rules.
So if you encounter such problem, try also this possibility.
However, I also leard few things during this, e.g. if you are working with SP instances from web scope, use web scoped features, not site ones, also, SP has a nasty habit to silent som exceptions. Also, if you e.g. take instance of SPWeb from event properties, it doesn't necessarily means it is already created. It takes some time, also, Update() itself is a thing that DB has to perform. Sometimes it's better to alsways check if you really have instance and if not, threadsleep for a while.
Have you used .Update() method in your code??