Can anyone describe the ways to call COM/COM+ objects from TIBCO BisinessWorks process, please. I cannot find such activities in my palette.
Thank you.
To communicate with COM objects from BusinessWorks, you need a BusinessWorks Adapter. Your can find information on the COM Adapter here: https://docs.tibco.com/products/tibco-adapter-for-com-5-3-1
The adapter is sold separately and not included in the basic BusinessWorks installation (separate licensing might be required).
Another way to do it is using a Java-Com Bridge like http://sourceforge.net/projects/jcom/
You might invoke it from BusinessWorks in a Java Activity.
You might evaluate cost of the adapter vs. effort of doing it "by hand" with a lib like this.
Related
I would like to subscribe to a RabbitMQ message queue from Excel 2013.
The ultimate aim is to allow data contained within a MQ message to be processed within Excel and to also allow Excel to send a formatted message via a RabbitMQ message queue.
Is this possible?
The message which is sent down the message queue is comprised of 7 fields, each field is delimited by a ; symbol - however the message is sent as one string over the message queue...
e.g. "text;number;number;number;text,text,timestamp"
I would like to be able to split the raw message as above, into formatted cells in Excel 2013.
Can this be done?
I have limited coding experience and I am trying to learn so please forgive me if this is a 'silly' question.
Any pointers will be much appreciated, for example can this be done via VBA code or an Excel Add-In?
Thanks in advance...
First, the bad news: there is no easy way to do this.
Now, the good news: if you really want to, you probably can do it, in at least two different ways.
Disclaimer I have not tested anything, cannot guarantee that it will work, and you (probably) will need to level up your coding skills to achieve what you want. These are just ideas that I would explore myself if I had requirements like yours, and should give you some pointers to get started. They're not necessarily good or functional.
There are various approaches to explore in order to achieve what you want:
Write an Excel addin in .NET to actually consume/publish to the queue. This may actually be the easiest solution, but it requires both Visual Studio and a bit of .NET knowledge. Some good resources to get started:
https://msdn.microsoft.com/en-us/library/bb157876.aspx and the always-so-good https://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html .
Pros: probably the easiest solution
Cons: you'll probably end up with an addin tied to your current requirements, and will have to update your addin when specifications change
Leverage COM Interop in .NET to write a wrapper DLL around RabbitMQ's .NET client library. If you've never done .NET, this approach may not be appropriate, as it will involve marshalling datatypes and function pointers. Some more pointers if you choose this (difficult) path: Easiest way to make .NET DLL visible to COM?. You can then import your COM wrapper into any Excel/Office project by adding the generated DLL to your VBA project.
Pros: you can create a generic wrapper that exposes RabbitMQ to Excel VBA and reuse it in any other Excel based project
Cons: the learning curve will be steep.
Use the STOMP adapter on your RabbitMQ server (if you have that option available, which may or may not be possible depending on your setup/sys admin), and write your own implementation in VBA. This is a bit hardcore, but works without any .NET voodoo, but you will need a special ActiveX control called MSWINSCK.OCX, and some event handling. StackOverflow has a question with decent answers samples here: MSWinsock.Winsock event handling in VisualBasic
Pros: once again, you can create re-usable code (via a class that you can import in other projects)
Cons: you have to implement a protocol, and it depends on an ActiveX control. Also requires the use of a RabbitMQ adapter, which you may not be able to use in your context.
I'm sorry that I can't provide actual code showing how you'd go at any of this, but as you've probably guessed by now, all solutions imply a fair amount of work. So at least, you know where to look...
I would like to call MQL4 or MQL5 function from my own imported DLL in Metatrader.
Is it possible?
Forest,
As far as i have experienced during the past 2 years working with MetaTrader, there is no real way to call MQL functions from an external DLL. But there are some custom built APIs that closely resemble to what you want to achieve:
MT4 API
MetaTrader™ Java / .Net API
These APIs do somewhat allow you to use MQL functionality out-of-the-box
Principle
After several hundred man*years in the FX domain, there is another approach to orchestrate a smooth and elegant MT4 Terminal co-operation with other processes than to try to push water up the hill or than to pay USD500+ for a kit, that will stop working right upon the next shock once Build 524-> Build 562->Build 586->Build 600->Build 609->Build 624->... moves again
A non-existent toy
Yes, MT4 architecture does not expose it's own interface to allow self to be "disturbed" by an undeterministic obligation to handle external low-level calls via DLL et al.
How to fix it
Nevertheless, it is possible to reverse the architecture and make MT4 Terminal act as a lightweight thin-Client, operating a smart messaging library, trough which the MT4 functions are being exposed for a remote call ( RPC ).
Example
This way a Python Node may collect MT4 data for numerical processing,
same way a PHP Node may in parallel handle remote-syslog-s,
same way a C++ Node may integrate another task,
same way another Python Node may act as a CLI terminal interface with a Custom-specific scripting-syntax language to command MetaTrader-side activities via command-line / stdio
simply -- whatever your application infrastructure needs can be done this way
( One may even improve a poor real-time features of the native MT4 threads to gain a much better soft-real-time predictability and a low-latency massively parallel architecture .. and still be on a safer-side, protected from being torpedoed by any next "new"-MQL4 )
nota bene: just to imagine the invisible threat, the headbang collision in "new"-MQL4.56789 is, besides others, that string, while being syntax-proposed as string, is not in fact a string but a struct and all your previous DLL-related work simply has to be re-worked and wrapped-around to emulate a string-as-struct or a new DLL-interface has to be designed for cases, which return a value in a buffered ArrayOfBYTEs, which MQL4.56789 side can receive and process, but which it cannot free on it's own and memory leaks.
If it's acceptable for your DLL to be a .NET DLL, then you could try
this MT4 .NET integration library called NQuotes.
With this library it's possible to access any MQL4 function from your DLL.
Here I am looking for a conceptual solution, plus some guidance. This is not an query that specifies an 'error in code/compilation/execution...' etc. Pl bear with the lengthy post.
My product is a desktop product written in VB.NET.
Another central team in office maintains a java code that does some computations, and releases jar to be used by whomever wants it. This team published APIs exposed by jar.
Users of this java jar were so far java developers, so everything was smooth so far.
Now, I am required to use the same jar and hence make calls to those exposed java APIs so that 'code is one, and used by any-and-many'.
Kindly pass on any useful links/code samples that helps me achieve this.
P.S.
1. I do not have a chance to go to any third party tools to make the bridge between Java & .net.
I am getting little bit understanding about JNI for such purposes, but am not getting a solid code sample that explains what should I do on C++ side to make a call to java functions.
And my team could put efforts to call C++ wappers from VB.NET
Thanks in advance,
I intend to add a COM interface to an existing application (which, by the way, is written in C++ using Win32). I have some experience using COM objects, so I know the basic COM concepts of interfaces, etc., but this is the first time I'm actually implementing a component.
Ultimately I want to be able to use the COM interface to automate my application from scripts such as VB. I understand that there are two steps:
My application must act as an out-of-process server (i.e. I have to use MIDL and generate code for a proxy DLL and a stub DLL).
Once I have the server I can add automation capabilities by implementing the IDispatch interface.
Since the server-in-an-EXE thing with MIDL and what not is already a bit steep, I wanted to get a grasp on all that first before moving on to IDispatch.
I am reading the book "Inside COM" by Dale Rogerson and have completed the chapter on servers in EXEs (the following chapter will cover Automation).
The "Servers in EXEs" chapter provides example code that implements a server and a client. But it is necessary to start the server manually. This confuses me. Obviously, when my application (= server) is used by a client process, this extra manual step should not be necessary. Is there no mechanism to start the server automatically? Or is automation necessary to achieve that? At the moment, the prospect of having to start my server manually (once I even have one) makes me doubt I am moving in the right direction.
Hopefully someone with more knowledge of this can see what information I'm missing and point me in the right direction.
No, COM servers are not normally started by hand. Not sure why the book proposed it, possibly because it wanted to avoid talking about the registry keys you need to allow COM to automatically start the EXE. It isn't otherwise very complicated, you register the Application coclass of your app with the LocalServer32 key value giving the path to the EXE.
It is however not completely uncommon, especially with an existing program. One design decision to make is whether you let the client code completely control your program. Or if your program already has an existing user interface but you also want to expose services to other code. In the latter case it makes sense to let the user start the app by hand, like she'd normally does.
When your application is registered as LocalServer32, it will be invoked with the commandline specified there if no running process has registered a factory object for your CLSID yet.
This way, you can get the best of both worlds -- if the application is running already, this instance can provide the server side, and if it isn't, it will be started.
Automation is completely orthogonal to that -- your component becomes Automation compatible by implementing IDispatch.
I have trouble understanding XPCOM. How is it different from COM? What makes it cross platform?
Is it a framework with a set of libraries that you can use to do some jobs?
Also, does Component Object Model means every functionality is implemented in component so we can use it without knowing the detail implementation?
Can you someone help me understand this please?
Thanks,
Chan.
I have trouble understanding XPCOM.
How is it different from COM?
XPCOM is Mozilla's own, cross-platform (hence the XP bit) version of COM.
What makes it cross platform?
It is implemented in a library that has been ported to many platforms by contributors to the Mozilla open-source project. You can build it or download a binary for any platform that you wish and, in the extremely remote possibility that you want to use it on a platform that is not already supported, it should be straightforward to port it yourself.
Also, does Component Object Model
means every functionality is
implemented in component so we can use
it without knowing the detail
implementation?
Yes, spot on. The idea is for a language-independent framework that enables different components to communicate and interact, without requiring any special knowledge of the language that any particular component is implemented in. So javascript code can call C++ code, for instance.
This is achieved by components publishing well-defined interfaces, using a language called IDL (or, in XPCOM's case, XPIDL). These interfaces make use of well-defined types with mappings in each of the supporting languages. Every interface inherits from a common base interface, which provides standard methods for reference-counting and type-inference (called IUnknown in COM and nsISupports in XPCOM).
Can you someone help me understand
this please?
In terms of online resources, there are dedicated areas on both the MSDN (for COM) and the MDC (for XPCOM). If you want to really understand the motivation for COM and why it is the way it is, I recommend picking up Don Box's Essential COM. And of course, if you have any specific questions that need answering, you can always come here to ask them. :)