I'm currently working on a project were am at the stage of figuring out what the current implementation is doing. Have been putting in a lot of time (A LOT) searching connections between queues declared as global variables.
Is there a way to get a listing of were a specific global variable is being used, or do I actually need to go through all processes, as I´m doing atm?
Thank you :)
in Tibco Designer 5.8 you can find where global variable is used using "Tools->Find Global Variable usages" menu item.
Please note that all tibco processes source code are text files. So, you also can search inside project folder using file text search from any utility that allowing you to search inside text files. For windows I prefer Far Manager
In the "Far manager" you can navigate to project folder then ALt+F7 and search for
%%GLOBAL_VARIABLE_NAME%%
Please also note that even if you don't have tibco project source code you can get it from tibco BW server. example path
tibco\tra\domain\tibco\datafiles\YOUR_PROJECT_NAME
Related
Using NiFi v0.6.1 is there a way to import backups/archives?
And by backups I mean the files that are generated when you call
POST /controller/archive using the REST api or "Controller Settings" (tool bar button) and then "Back-up flow" (link).
I tried unzipping the backup and importing it as a template but that didn't work. But after comparing it to an exported template file, the formats are reasonably different. But perhaps there is a way to transform it into a template?
At the moment my current work around is to not select any components on the top level flow and then select "create template"; which will add a template with all my components. Then I just export that. My issue with this is it's a bit more tricky to automate via the REST API. I used Fiddler to determine what the UI is doing and it first generates a snippet that includes all the components (labels, processors, connections, etc.). Then it calls create template (POST /nifi-api/contorller/templates) using the snippet ID. So the template call is easy enough but generating the definition for the snippet is going to take some work.
Note: Once the following feature request is implemented I'm assuming I would just use that instead:
https://cwiki.apache.org/confluence/display/NIFI/Configuration+Management+of+Flows
The entire flow for a NiFi instance is stored in a file called flow.xml.gz in the conf directory (flow.xml.tar in a cluster). The back-up functionality is essentially taking a snapshot of that file at the given point in time and saving it to the conf/archive directory. At a later point in time you could stop NiFi and replace conf/flow.xml.gz with one of those back-ups to restore the flow to that state.
Templates are a different format from the flow.xml.gz. Templates are more public facing and shareable, and can be used to represent portions of a flow, or the entire flow if no components are selected. Some people have used templates as a model to deploy their flows, essentially organizing their flow into process groups and making template for each group. This project provides some automation to work with templates: https://github.com/aperepel/nifi-api-deploy
You just need to stop NiFi, replace the nifi flow configuration file (for example this could be flow.xml.gz in the conf directory) and start NiFi back up.
If you have trouble finding it check your nifi.properties file for the string nifi.flow.configuration.file= to find out what you've set this too.
If you are using clustered mode you need only do this on the NCM.
I have a unit test project for my VB.NET solution that takes a very large data set (multiple Gigabytes). The data set is static, outside of source control (developers unzip a big .zip file somewhere on their machine)
I'm trying to figure out how to reference this data set inside my project and I'm having trouble because of the following constraints:
The data set may be in a different location on each developer's machine e:\dev\MySolution\TestProject\ vs. c:\MySolution\TestProject\data. We can require it to be in the project folder but I can't require that the project folder be in the same place. This means I can't store the path in source control or I need some way to override it.
Because of its size I don't want to have to copy or deploy the test data at runtime because this will slow things down a lot and I don't want to have two copies of it.
My hack-y solution is to use a project property called DataPath and reference this inside each test. Then users would just change the property and I'd instruct them not to commit this change.... feels like an anti-pattern though.
My initial thoughts were to somehow store the path in the project.suo file which is outside of source control but I can't figure out how to make that work.
Anyone have experience with this?
I'm looking to break my access applications out into their component pieces so that I can use some version of source control with it. I currently have separated the front end and back end database. However I would like to go one step further and separate out the front end logic in the forms into their component files. If someone could point me in the right direction it would be much appreciated.
Access for about 20 years has supported the standard source code control interface.
The fact that the project is stored in one file is MOOT since Access can “logically” view each individual item (forms, reports, query, code etc.) as a separate object. So don’t confuse a logical view of the application vs that of physical.
There are quite a few posts on SO that outline this, and this post here gives some more information:
Version control for VBA file
When you use SCC with Access, then you see this:
if using Visual Source safe, you see this:
If using Team foundation server, you see this:
And the UI inside of Access shows the status of such objects. eg this:
There also add ins for git hub etc.
Keep in mind that Access 2010 was/is the last version to support SCC. If using 2013, then you have to use the noted "save-as-text" to send out each part and code as a standard text file which then of course can be used by any standard source code provider/control system.
I have created a process in IBM UCD to deploy a .Net application.
My Scenario is that i should be able to provide different application name at run time each time i run the process. How can we do this using property in IBM UCD.
I have tried enabling "Prompt on use" option and also created component property and mapped it to the parameter say ${p:component/application.name} but doesn't seem to work. May be i missing out some sequence of steps.
It would be great if i get detailed steps to making this working.
I take it that you are on version 4.x (uDeploy)?
I would steer clear of the prompt on use approach, that feature was removed in 6.x. While there is a migration in place, its simpler to just avoid it.
Using a property on the component process itself is the way to go. So go to your process configuration, and go to the properties / configuration tab. Create a property there. You'll be prompted for a value whenever you run an application process that uses this component process.
If the property is named "iis.app.name" you would reference it with just ${p:iss.app.name}.
Don't use the property "application.name". That is an automatically created property that gets the name of the UCD Application that you are deploying. If you ever can't find out the right way to reference a property, look at your executed process (at component / application levels). The normal view that lists out all the steps that were run and how long they took is sitting on a tab called "Log". Right next to it is "Properties" tab. Click that and you'll see what properties were available to the process.
Also, you'll have better luck getting fast answers about UC Deploy using their own forum: https://developer.ibm.com/answers/?community=urbancode
Did you tried using process plugin for updating the property file ?
Application >> Process >> Select Process >> Process Editor -- From left panel you can Utility plugins , try with update property option.
My small collection of document-specific macros and quickpart building blocks is growing! I'm starting to share these with employees, and am looking to be able to set up each remote computer once only. From there on, update collections on a network path. And because each computer looks to the shared location, everyone should always be working with up to date macros and quickparts etc.
So. What I already know:
- Required macros are saved in a separate module, ready to be shared/exported.
- Macros themselves occasionally reference local paths on my computer.
- I will need to reference paths with generic code or use Environ variables.
- Building blocks and quickparts are saved in a separate template file (currently located in Appdata, along with default building block file).
What I dont know:
a) How to point Word to a network path to retrieve macros from custom macro files. (Would I just have to import a fresh macro file at every important update, on each PC?)
b) What's the best way to load a building block item from a CUSTOM path?
My custom BuildingBlock template file is not loaded properly on occasion:
Dim objTemplate As Template
Dim objBB As BuildingBlock
'set template to store the building block
Set objTemplate = Templates("C:\Users\[USER]\AppData\Roaming\Microsoft_
\Document Building Blocks\1033\CustomBBlocks.dotx")
Set objBB = objTemplate.BuildingBlockEntries.Item("[EntryName]")
I know this because the code spits out a 'CollectionDoesntExist' error unless I click the Quickparts gallery prior to running the code for the first time. So it's like Word cant be bothered to open the template file and look inside unless I do it from the UI first.
Of course, if I first open the Quickparts gallery from the UI, prior to running my code, Word seems to figure it out, and inserts the correct Building Block entry without any issue.
In the past I've worked on a product that allows building blocks for Word too. Some sites have hundreds of templates and maybe 1.000 elements (see Composition). The approach we've taken was successful and was different.
You are trying to deploy software elements (macros) across a large number of workstations. You can try to get it working using the possibilities of Microsoft Word and Windows, but it will be sensitive to problems when things change. For instance, switching to Office 2013, splitting a domain into two, work at home without VPN, etc.
Option 1 - DIY deployment: Better put the macros and other stuff behind a webpage, webservice or alike. Deploy on each workstation a generic program that pulls in everything and deploys it locally. You might want to hand over some parameters to the webpage being called to restrict the amount of data. You might want to cache things locally.
Option 2 - Use ClickOnce: write a clickonce deployment script, include the necessary references and put it on a shared network drive or http address. ClickOnce automagically upgrades your software when it finds a new version. It even works across the internet. And it does nothing when there is no new version.
Option 3 - Database: put the elements centrally in a database, allowing end users to change building blocks through forms. Have Microsoft Word in combination with a ClickOnce program pull them in.
For Composition we've used option 2 and 3.