I want to track my custom activities' property values in my own tracking service, .i.e. I don't need it in the built in SQL tracking service. I have been successful in reproducing the SQL tracking service in that I can see the worklfow and activity states etc. but I want to see property values also.
We are writing many workflows for a document management system (DMS) using its own workflow engine that is based on MS WF. I can therefore not change the workflow runtime (if it was needed). The solution has to work with the embedded functionality of the underlying Microsoft workflow runtime.
Our workflows typically do database lookups through custom activities we write. These lookup values are then passed on to other activities for program flow or for persistence into the DMS. It would be great if we can see what these lookup values are at runtime and in fact the values of the DMS own activities' properties.
From my (admittedly limited) knowledge of MS's Workflow, the correct approach is to publish updates to your tracking service from within the workflow -- ie, if your workflow does some step, it should go to the tracking service and say "I did X". Your tracking service can record this information to answer any subsequent queries about what the workflow did (and what the various property values were at the time).
The essential point is that the WF engine is useful for running workflows - but is not very good at reporting on the progress of those workflows.
If you do have some control over the WF engine (you say its "based on MS WF") then one option may be to make your WF Engine publish such updates for all workflows. That may allow you to forgo explicit updates within your actual workflow definitions. However, if you really can't make any changes to the engine, then this won't work.
Related
Apex code to create a record picklist in an object when a new member is created in another object?
Picklist value sets cannot be mutated directly in Apex. You would have to make a callout to the Metadata or Tooling APIs in order to achieve this, which cannot be done in a trigger, so you'd have to use Asynchronous Apex.
Making automated changes to metadata is a complex and somewhat risky implementation. Because the running user of the trigger in many cases will not have permission to call those APIs at all, you'll likely have to use a Named Credential-based approach to authorize as a specific System Administrator.
This implementation does have security considerations and involves a lot of complexities and considerations around change management. It should be carefully considered by the org's architecture stakeholders.
We are able to provide an initial training model and ask for recommendations. When asking for recommendations we can provide new usage events. Are these persisted at all into the model? Do they manipulate the model at all?
Is there another way the data is supposed to be updated or do we need to retrain a new model every time we want to enrich the model?
https://azure.microsoft.com/en-us/services/cognitive-services/recommendations/
EDIT:
We are trying to use the "Recommendations Solution Template" which deploys a solution to Azure and provides a swagger endpoint for working with the model (https://gallery.cortanaintelligence.com/Tutorial/Recommendations-Solution)
It appears the Cognitive Services API is much richer than this. Can the swagger version's models be updated?
After more experience with this I discovered a few things as of August 21st, 2017:
While not intuitive for the uninitiated, new data requires training a new model for the data to be persisted into the model.
This allows a form of versioning the model, and means when you make new models you can switch recommendations to work how they did before if they don't work as well.
The recommended method appears to be to batch usage data and create new builds of the model on an interval.
The APIs do allow passing in recent usage data to allow recent data to be accounted for at scoring time, it's just not persisted.
The "upload usage events" call in the cognitive services API does not seem to work. Uploading the new usage data via a file does appear to work.
The Recommended Solutions Template vs. The Cognitive Services API
It appears the Recommended Solutions Template is a packaged version of the SAR (Smart Adaptive Recommendations) model inside the Cognitive Services API that is optimized for ease of use.
I'm presuming for other popular recommendation models like FBT the Cognitive Services API should be used as the deployable template only allows one model type.
Additional note on the Preview Status of the API
It seems microsoft is deprecating the datamart as of February and sending people to this preview API instead. Therefore it seem reasonable to presume this Preview is highly likely to move on past preview and not be killed.
I'm trying to create Siebel workflow for a new business requirement, I've checked Siebel Bookshelf and I'm bit confused with the flow. Especially I'm having difficulty in understanding the relationship between Workflow policy object, Workflow policy column, workflow policy component, workflow policy component col and how database triggers are created.
Can someone help me to understand these concepts better?
Workflow policy objects and components are very much like the business logic layer objects and components that support the Siebel GUI. A Workflow policy object might be Account, and its components could be Account, Account Contact, Account Address, etc.
Workflow policies themselves are still (I think) created in the Siebel GUI on the server. If your policy conditions are based on a custom field, you might have to add this to the workflow policy component involved using Siebel Tools.
The columns are the set of fields that the triggers are generated for and that Siebel workflow policy will be referenced against. The Siebel monitor components wake up when the trigger is fired, check the policy conditions, and then run whatever processes are attached to the policy.
Once the policy is defined, the generate triggers command needs to be called against the database to include the new trigger details your policy has created. This can be done using Siebel server manager or using SQL directly against the database. Check the Siebel Business Process Framework: Workflow Guide for more details on these steps and how to validate you work.
We are using Integration Manager to create a batch of monthly invoices. I want to build a replacement that creates a batch in GP and imports the invoices into the batch. After review, the batch will be posted to GP. Is this doable with either of these API's and which would you choose?
Integration manager can use econnect for its insertion engine. If you are processing a high volume of transactions, you will notice a huge difference between integration manager's UI engine and econnect. When you create a new integration, simply choose the econnect option and whatever data source you have set up.
Concerning the non-IM APIs, both may be used, and they are situational. The web services sits on top of econnect, and it is much slower integrating because you are passing information between several layers. It does provide a secure link between your SQL server and any outside integration sources, and it is ideal if you need to setup something to allow integrations to happen through middleware such as a billing gateway. If you have access to build an econnect process/app that makes a connection to your SQL server for GP, this is the fastest way to integrate SOP and receivable transactions. It maintains all the business rules to help ensure GP does not break in as a result of a patch, and the speed is fast enough to push thousands of records without requiring a custom integration solution.
If you want to get done quickly, and do not mind working from the integration manager interface, just build your integrations using econnect. If you have the time to develop a custom integration routine, go for econnect. If you want to leverage WCF technology on top of econnect, go for web services.
Each are listed in the amount of time it will take you to develop from fast implementation to slower implementation.
MS CRM Dynamics 4.0 incorporates the MS WF engine. The built in designer allows the creation of sequential workflows whos activities have native access to CRM entities.
Is it possible to:
Create a state machine workflow
outside of CRM (i.e. in visual studio) and import it into CRM?
Have this workflow access the CRM
entities?
It is NOT possible to create a state machine workflow for use in MSCRM.
It is also not supported to create any workflow outside of MSCRM and import it.
As a work around you could write either all the logic you need into a custom workflow activity and import that into MSCRM and have it called from a normal workflow.
The other option is build a seperate application which runs a state machine workflow and interacts with MSCRM via the web services. You could (would need to?) combine this with a custom workflow activity to kick off processes.
It is possible to create no code workflow...
http://blogs.msdn.com/jonasd/archive/2008/01/21/Creating-a-no_2D00_code-workflow-for-CRM-4.0-with-Visual-Studio-2005-_2800_2008_2900_.aspx
and take a look at the other thread...
Is is possible/a good idea to edit workflows in Visual Studio?
I don't know the answer to your specific question, but hopefully this information will point you in the right direction.
The "native" format for WF workflows is ".xoml" files. These are basically identical to XAML files, and both are nothing more than generic persistence formats for a .NET object tree. If you can access the saved data that is output by the Dynamics designer, it should be in the same format. If it is, you should be able to open it from the Visual Studio designer.
The key here is that CRM undoubtedly defines its own set of custom activities that you'll need to be able to reference from within the alternate designer. With any luck, these will be in assemblies with obvious names and/or in the GAC.