How can you programatically export a BizTalk receive location?
And extending the question ... receive ports and send ports
There's a few ways to approach this, each with benefits and drawbacks.
WMI: http://msdn.microsoft.com/en-us/library/aa547992.aspx
The drawback is this is by Assembly, so you'd have to enumerate them first.
BTSTask.exe: http://msdn.microsoft.com/en-us/library/aa559686.aspx Better, since it allows you to specify an Assembler or an Application. There's no object model, but executing from another program or script works fine.
PowerShell Provider for BizTalk: http://psbiztalk.codeplex.com/
The way to go if you're scripting in PowerShell already.
You should just be able to export the bindings to an xml file and import them in your target environment. This article outlines the steps...
http://msdn.microsoft.com/en-us/library/aa560753.aspx
Further if you are going to be doing deployments to multiple environments you should look at the BizTalk Deployment Framework...
http://biztalkdeployment.codeplex.com/
Related
I am novices to the field of Identity and Access management.
Till now I know, Sail point has provided the some direct connectors to integrate the known systems like LDAP, HR systems, OIM, Databases..
And sailpoint also provided the support for disconnected applications with the use of Custom connectors.
Here, My question is how to develop a custom connector..?
I do not have jar file provided by sailpoint which contain "AbstractConnector" class.
So that I can write my own class and develop..?
I also so not understand, what to do with that class?(if i have a jar)
How sailpoint will refer to that class..
Do we need to deploy that class to somewhere...
Here I am expecting the complete flow to develop and deploy the custom connector..
If anyone is working please help..
If you unzip your identityiq.war, you'll find a JAR file called WEB-INF/lib/connector-bundle.jar. This is the JAR where you'll find AbstractConnector. Once you've written your connector code, you will need to compile it and bundle it into a JAR file, which you will place into WEB-INF/lib.
Finally, you will need to update the ConnectorRegistry object (under Configuration on the debug screen) to reference the new class, which will make it available as an Application type. If it has custom connection parameters (as most do), you will also need an xhtml page that will be embedded into the Sailpoint UI to prompt the user configuring the Application.
If you have Compass access, they have a whitepaper called Custom Connectors that you will find helpful.
All that said, I encourage you to try to find a way to use an out-of-box connector if possible.
Most of the times it will be better if you use the DelimitedFile connector, you can import a CSV of identity data, and make it work within Sailpoint's workflow. You will be able to map fields, correlate accounts and create multi-valued group memberships rapidly. Of course, this means that Sailpoint will not be connected directly to the application, and you will have to develop a workflow to extract the identities and upload them. But at least, you can integrate without going the Custom Connector way.
I've seen api-paste.ini as a conf file after installing openstack.
It looks like substituting some prefixes for python implementation but have no clue about this.
Here, my questions are:
What script is it?
it looks like very bizarre grammar like the following:
[composite:metadata]
use = egg:Paste#urlmap
/: meta
How does it work within python script?
See documentation for Paste Deploy.
The api-paste.ini is the configuration for the above web-services framework. Paste.deploy allows you to separate concerns between writing your application and middleware/filters from the composition of them into a web service. You define you WSGI applications and any middleware filters in the configuration file then you can compose pipelines which include the middleware/filters you want into your web-service, e.g. authentication, rate-limiting, etc.
You want to temporarily remove authentication, take it out of your pipeline and restart your web service.
The declaration above is declaring a composite application, but with only one application binding (a bit unnecessary - normally you would expect to see more than one binding, e.g. for different versions of the application). The WSGI application app:meta will be bound to / and you should have a declaration of app:meta later in the file. The implementation of the composite app is declared via the use and the egg:Paste#urlmap is a simple reference implementation.
You load this in your program with paste.deploy.loadwsgi.loadapp().
There is a proposal/recommendation(?) to move away from Paste Deploy/WebOb to WSME/Pecan see OpenStack Common WSGI
I'm moving from IBM RAD 8 / WAS 7.0 to IBM RAD 9 / WAS 8.5. Liberty Profile. There's a plenty of configuration things such as URLs and namespace bindings.
I've found an information that WSADMIN is not working for Liberty Profile. I haven't found, however, the information, how to access similar functionality as in wsadmin/jython, for example for creating URLs, namespace bindings, etc.?
How to script such things under WebSphere Liberty Profile?
I'll try to address a few things that are implied by your use of wsadmin. I may be overshooting, but I hope this helps:
WSADMIN applies only to the full WebSphere Application Server. jython scripting for the Liberty profile is possible, though you're basically performing JMX operations on a server. Here is something to get started with: https://www.ibmdw.net/wasdev/docs/creating-remote-jmx-connections-with-jython/
There is no way to reconfigure a Liberty profile server via a JMX operation, however. All server configuration (or reconfiguration) is done by editing the server configuration file (either manually with an editor of your choice, via the eclipse tools, or with a script that modifies your XML).
The Liberty profile does not support CORBA or CORBA namespaces (corbaloc or corbaname), or remote EJBs. Liberty profile servers also are not part of the cell/node topology of full profile servers. Instead, Liberty profile servers form collectives, as described here:
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.core.doc/ae/cwlp_collective_arch.html
You can add strings to JNDI using the jndiEntry element in your server configuration as described here: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.core.doc/ae/twlp_dep_jndi.html
Information about configuring datasources (I am guessing at what you might need URLs and namespace bindings for) is here (see also the subtopics): http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.core.doc/ae/twlp_dep_configuring_ds.html.
The easiest way is to edit the XML directly or using a script in the language of your choice. The idea is that the config is simple enough wsadmin is no longer needed - it's intended to be human readable and human maintainable. You can import XML snippets if you have repeated config elements you want to share similar elements across multiple servers, or create the same config elements multiple times.
I was trying to consume an already written WCF service into my BizTalk orchestration. But while configuring the ports and port types for the consumption, found that the 'WCF service consumption wizard' in Visual Studio offers HTTP transport-type as the only option and no WCF-BasicHttp/WCF-WSHttp transport-type options are available.
However, we can always do the required WCF-BasicHttp/WCF-WSHttp settings by importing the required bindings file from the BizTalk Admin Console, Is there a programmatic way for the developers to do the same from inside the Visual Studio (instead of specifying those bindings later from the Admin Console)?
The binding files are just XML, so you can create those programmatically. Modify the XML as you see fit, either by hand (e.g., in the built-in XML editor) or by using some sort of custom code.
Typically we use multiple binding files per environment, including one that just works with everything on localhost for developers. You just pick the one that you want and import it into BizTalk or write a script automatically import it for you (such as after build).
You can also take a look BizTalk Deployment Framework. For more of that.
Michael Stephenson has a great post on using MSBuild to automate your deployments, including the BizTalk binding files, here.
I'm sure there's a simple explanation for this, but I haven't had much luck at finding the answer yet, so I figured I'd put the word out to my colleagues, as I'm sure some of you've run into this one before.
In my (simple) dev environment, I'm working with a handful of WCF Web Services, imported into my FB3 project and targeting a local instance of the ASP.NET development Web server. All good, no problems -- but what I'd like to know now is, What's the right way to deploy this project to test, staging and production environments? If my imported proxies all point, say, to http://localhost:1234/service.svc (from which their WSDLs were imported), and all I'm deploying is a compiled SWF, does Flex Builder expect me to "Manage Web Services > Delete", "> Add", recompile and release ever time I want to move my compiled Flex project from development to test, and to staging, and ultimately into production? Is there a simpler workflow for this?
Thanks in advance -- hope my question was clear.
Cheers,
Chris
If you have path names which will change depending on the enviroment then you will likely need to recompile for each environment since these will be compiled in the swf.
I typically use ANT scripts to handle my compile/deployment process when moving from development and production environments. This gives me the ability to dynamically change any path names during the compile. These build files can be integrated into Flex Builder making this process very easy once you have everything set up, and can be done with one click or scheduled.
Thanks Brett. I've been meaning to dig into automating my build processes anyway, so now's probably as good a time as any. :)
You do not need to build a SWF for each environment. Here's a technique I use commonly:
Externalize your configuration properties into an XML file; in this case, it could be a URL for each service or a base URL used by all your services
When the application starts up, make an HTTPService call to load the XML file, parse it, and store your properties onto some bindable "configuration object"
Bind the values from that object against your objects that depend on the URLs
Dispatch an event that indicates your configuration is complete. If you have some kind of singleton event dispatcher used by some components in your app, use that, so that the notification is global
Now proceed with the rest of the initialization of your application
It takes a little work to orchestrate your app such that certain parts won't initialize until steps 1-5 take place. However I think it's good practice to handle a lot of this initialization explicitly rather than in constructors or various initialize or creationComplete events for components. You may need to reinitialize things when a user logs out and a different user logs in; if you already have your app set up to that initialization is something you can control then reinitialization will not be a problem.