It's not particularly structured, but hopefully there's some nuggets of useful information in there for you, please don't hesitate to call out if you have a further specific question.įirstly as you say, it can be a lot easier to conduct some things in Java (Groovy), or Javascript rather than laying all logic out as activities and transitions, over time you get a natural feel for what is appropriate where and you seem to be well on your way to forming your own style of when to do what. Your comments so far, indicate you've done a fair bit with the workflow engine, so I thought I'd try and give you a bit of a tips & tricks braindump. Makes more sense using them in fully custom written API-Client. Using HTTPClient Requests and adding overhead logic to check the replies would bloat Workflow Screen quite a bit. CVDB, XML-Requests and Java-Code are already plenty to have issues with. In general I don’t like to mix so many different Attack-Vectors. Having different ID-System in some places was also annoying, though that seems to be mostly aligned in fr20 now. Yeah we don’t use Plans yet and still wait for them to get usableĭocumentation only shows you one or two Samples with carefully selected Attributes, but rarely explains what they mean, which are mandatory or optional and what Values are available. Intended to use it for Automation to register and configure new Clients back in SP14, but half of the Operations are not available and for the rest you need a university degree to collect all the needed infos from two dozen concated api calls. It is still super limited in FeatureSet (as of FR20). Knowing Java is definitely useful.įeedback like this is great, did you know you can post feedback in documentation? It might be worth doing that as well as it will trigger a review in the background that may end up giving you what you want for future documentation versions.ĪPI is in some parts even worse if I’m honest Already using it to configure Things that weren’t available as QCommand-Activities or that do not have xml-Requests documented, like setting OperationWindows. We do really rely on some of the advanced knowledge to be understood without teaching it. Take a look at the and use postman and API calls you need and then just add them in to the HTTPClient in the workflow passing the results from one to the next as needed. Just wanted to see if using the HTTPClient (to call APIs) will help reduce the complexity for you?ĬommServeDBQuery mean you have to know the DB very well and I have seen some very deep knowledge of flag codes etc to really guarantee you are getting what you expect in to the results. Hoped the Lego-Stuff would be part of the Essential-Docu and those Scripting-APIs be expanded upon in Expert, maybe that will be Part of the “Hardcore”- or “Admin”-Sections :-D But that one is a good example on how rich on advanced Options the Workflow-Engine is, above and beyond the Lego-Block simplicity. Trying to accomplish that with Switch/Desicion/AssignValues Blocks gets messy fast.ĭon’t intent to use it as excessive as Devs did in “End User Automation” Workflow. Or to catch Error-Conditions that Execute-Block doesn’t catch itself and diverge execution path based on that. It’s way more flexible that way, reading Input-Values or Result-Sets, creating new Strings depending on complex conditions and writing them out to Variables for other Actvity-Blocks to use.
The latter ones are what I am interested in. Ultimately I end up using mostly CommServeDBQuery to retrieve Data from DB and Execute Blocks to run xml-Requests, sprinkling of some helpers like ExecuteScript, LogEvent or ResultSetToText, glued together with Conditional Connector or Script-Blocks. Operation-Backup being unable to run HANA DB Backup). Create-Subclient cant manage Excludes or FS-Options) or even outdated (f.E. I know the Drag-And-Drop Activities, tried most of them.
0 kommentar(er)
