I am new to K2 Blackpearl. I have searched the web for a description of what a Folio is. Can someone please explain what a Folio is in K2 Blackpearl?
Folio is a process level property which can be used to differentiate various instances of a workflow. Lets consider a scenario - you have a K2 Approval workflow for Bill Request of different markets.
We can set Process folio as : " "Market" - Bill Request" which will help the end user to distinguish it . We have a unique Process ID for every workflow but that is of no use for an end user.
Process Folio can be set either when it is triggered from smart forms or Web Services and in the workflow using Data Event or Server code Event.
The best way to think of a Folio is as the subject line for a process
Folio is a Title for each process instance. Try to keep your folio unique for each instance in for a particular process. I normally add ID or Process Originator name to folio which helpful when you need to troubleshoot any instance as you folio name is informative. Below is an example,
If I have a workflow to Approve Documents.
Process Name: DocumentSignOff
Folio: DocumentSignOff-[ProcessInstanceID]-[Originator]
i.e. DocumentSignOff-1254-JognDoe
Basically in K2, a folio is a description that tags one WF task submitted from the other. The best way to create a folio, is to ensure that, every task submitted gets to be concatenated to a Process InstanceID.
For instance: Cash Advance for Wallace Cole - 17893
Appending process Instance ID to every task submitted is one of the best ways to track task submitted,using the Process Instance ID or in short ProcID.
Related
Product Use Case - Our product has a typical use case where we will be having n no of users. Each user will have n no of workflows and each workflow can be run at any time(n of time).
I hope this is a typical use case of any workflow product.
can I use a domain to differentiate users (I mean to say that creating a domain per user)?
Can I create one WorkflowClient per user to serve all his workflow executions? Or for each request should I need to create one WorkflowClient? which one is a recommended approach?
What is the recommended approach in creating Worker objects to poll task list?
Please don't mistake me If I have asked anything meaningless
can I use a domain to differentiate users (I mean to say that creating a domain per user)?
Yes, especially when these users are working in different teams or product, using different domain will avoid workflowName/IDs conflicting each others, and also assign independent number of quotas for managing traffic.
Can I create one WorkflowClient per user to serve all his workflow executions? Or for each request should I need to create one WorkflowClient? which one is a recommended approach?
Use one WorkflowClient for each domain, but let all WorkflowClients on the same instance share the same TChannelService to save the TCP connection.
I would start with a single namespace (domain) for all users. Unless your users directly operate their workflow implementations it doesn't buy you much to use multiple namespaces.
I need to have a unique identifier within the Email subject. Is it possible to use the RecordId of the Entry within a workflow email?
I've tried using {record.id} within the Message/Subject field and it only returns the value of 0.
Any help would be greatly appreciated.
Found out that {record.id} isn't populated on submission (for obvious reasons). You can't use this within the "When the form is submitted..." workflow. But you can use use it during the "When the form is approved..." workflow.
I have a requirement to create CQ pages programmatically. But the challenge is that the page name/uri should be autogenerated combination of a string + unique number (eg. PT2000, PT2001).
Can someone tell me a way way to generate an autoincrement-id/constant in CQ in a way that the id's are unique even with multiple concurrent request?
Use a service that provides you with the ID and that manages the counter inside a volatile instance variable to make sure that state changes by one thread are immediately communicated to all other threads.
This should do the trick as long as your can guarantee that your implementation runs on a single author node. In a cluster scenario you additionally have to care about executing it only on one node.
i'd suggest creating a service that manages its counters somewhere in the repository, and also acts as a jcr EventListener. the service should listen for NODE_ADDED events on parent nodes of type cq:Page, and once onEvent is called, it can assigned the unique id at that point. you'd want to use synchronization obviously so that overlapping calls to onEvent() won't use up the same id.
You can use a GUID, Graphic User ID, the ID generated has a great probablity of uniqueness.
See wiki reference http://en.wikipedia.org/wiki/Globally_unique_identifier
and to create GUID:
Create a GUID in Java
This will ease you effort to verify the number is unique so just generate the ID and create the pages with that ID.
Doesn't AEM automatically append numbers to same name pages?
If it doesn't, then presumably this would fail, at which point you start over with the next number. Best guess should be enough in this case.
Sorry if this is sort of confusing because I'm not sure how to word this. I am trying to create a workflow that runs off of Account's in Microsoft CRM 2011. One part of this workflow requires me to retrieve a field contained in the Business Unit of the User in the Account's "Created By" field. However, the workflow will only allow me to access the Business Unit itself, but not any of its fields.
I'm wondering if there is a simple trick or work-around that will allow me access to this data.
Thanks!
For reference, the Account has a User, who has a Business Unit, and the Business Unit has a field I need to access. CRM, however, doesn't want to let me get more than 2 levels deep when accessing fields.
Clunky but do-able if you accept a bit of denormalisation (temporarily or otherwise). I'll assume for the sake of example you want to get at the "cost centre" field from the BU.
Add a field on User entity to temporarily hold the value from the BU (so make it same type and length, text(100) in this case), optionally put it on the form.
Create a child workflow for the User entity to update the user with the "cost centre" value from their BU. Make it only available to run as a child, not onDemand or anything else. Activate
In your Account workflow, add a step to call the child workflow against the relevant user (eg Created By in your case).
Add a step to wait until the new cost centre field on the user record contains data.
Now do whatever you need to with the value from the user record, such as update the Account, or do some branched logic.
Whatever you do, once you have used the value, clear the field on the user record, or do this as the last step of the workflow.
Now, since Users don't change BU very often, you might actually just go ahead and keep that value on the User record permanently, and instead of a child workflow, simply run this on create of a new user, or on change of BU, and store the value permanently on the User record. Yes, it is 'denormalised' and not purest SQL design, but then you don't need a child workflow, you don't need a wait state and you don't have to clear the value at the end, or worry about what happens when two Accounts need to run their workflow at the same time. I include the more general approach above as this might apply to other records which do change their parent quite often.
Just an additional thought - you can access the "owning business unit" of the Account, but this will be the BU of the Owning User, rather than the Created By, but is your business process such that this would normally be the same person? (eg users only have Create priviledge to "user owned" depth, so can only create records they own).
If so, then you could get at the BU directly from the Account, and then any fields on it too (in a condition or to update the Account)
Alternative which is less ideal but a similar approach - add a relationship from Account to BU (eg "created BU"). Now you can update the Account with this by referring to the Created By User's BU, then in the next step, reference this value from the Account. This is again denormalised, and less preferable since number of Accounts is far greater than number of users, so the level of duplicate information is much higher.
You can't get deeper with the standard steps of a workflow.
The solution is to create a custom workflow activity, you can start from this article:
http://msdn.microsoft.com/en-us/library/gg328515.aspx
I have begun digging around in the Google Cloud Print project in hopes of creating a custom application for my network. I have a Windows Print Server running with a printer queue I wish to submit jobs to. Setup the Google Cloud Print with the Crome browser and I was able to submit and print jobs just fine. However, my end goal is a little more complicated.
I need to customize the access control from the server-side client endpoint once the job reaches my network. Meaning, once the job is submitted, I need to be able to check the username of the owner of the job and process accordingly. From the looks of it, the /fetch interface does not store the original owner of the job, just the end owner of the queue it ends up on. Meaning, User A has the Google Cloud Printer linked to their account and has shared it with User B. User B submits a job to the shared queue. When I run /fetch on the shared printerID the user is User A.
Has anyone else dabbled with this?
Thanks
Take a look at the ownerId of the job.
The /fetch call does in fact return a user field containing the owner of the printer (User A), but the specific job(s) returned contains an ownerId field with a value of the user that submitted the print job (User B).
Hope that helps.
Following is a partial response from a /fetch call, including ownerId of the job. Keep in mind that this could be one of many jobs that are returned in the jobs array:
...
updateTime: "1403628993840",
status: "QUEUED",
ownerId: "rpreeves#gmail.com",
rasterUrl: "https://www.google.com/cloudprint/download?id=5ca7b1e4-c533-c42b-7d2b-efb862c4215a&forcepwg=1",
ticketUrl: "https://www.google.com/cloudprint/ticket?format=ppd&output=json&jobid=5ca7b1e4-c633-c42b-782b-efb862c4215a",
printerid: "f33c6ff8-fc25-7075-249b-ab65c3e2354e",
...