Anybody knows if it's possible to create a new package using a flow service in webMethods developer 7.1. What I want to do is to create a flow service that takes as input a string (package name) and as result it's going to create the new package with the string as name. Does exist anything in developer that I can call from my service and it creates the packages automatically instead of File -> New -> Package?
Thanks!
There is no public/documented way of creating a new package programatically as far as I know. However, if you don't mind using private/undocumented services, and understand that doing so would not be endorsed by SoftwareAG, then you can do the following:
If you can't see the WmRoot package in Developer/Designer (this is by design, since it's considered private) you can add the following configuration key to the file ./IntegrationServer/config/server.cnf:
watt.server.ns.hideWmRoot=false
Use the service WmRoot/wm.server.packages:packageCreate to create a new unactivated package. Unfortunately the inputs and outputs to this (and most other WmRoot services) have not been declared, but you just need to add a String variable called package set to the desired package name to the input pipeline to call it.
Use the service WmPublic/pub.packages:activatePackage to activate the new package.
For bonus points, you can programatically create new services in your package as well using the service WmRoot/wm.server.services:serviceAdd (this is one of the few services in WmRoot that mercifully does declare its inputs and outputs).
Alternatively, if you do not wish to use private/undocumented services, you could create your own service to create a new package relatively easily. Since a brand new package is just a collection of empty directories and a manifest.v3 file, you can write your own service to create these directories and files and then call WmPublic/pub.packages:activatePackage to activate it:
IntegrationServer/
packages/
<package_name>/ - create this directory with the desired package name (MANDATORY)
code/ - create this directory (OPTIONAL)
classes/ - create this directory (OPTIONAL)
jars/ - create this directory (OPTIONAL)
source/ - create this directory (OPTIONAL)
doc/ - create this directory (OPTIONAL)
lib/ - create this directory (OPTIONAL)
ns/ - create this directory (OPTIONAL)
pub/ - create this directory (OPTIONAL)
index.html - create this HTML file as a placeholder home page for the package (OPTIONAL)
resources/ - create this directory (OPTIONAL)
templates/ - create this directory (OPTIONAL)
web/ - create this directory (OPTIONAL)
manifest.v3 - create this XML file by copying the structure from another existing package (MANDATORY)
As you can see, the only things that are actually required to create a new package is a new directory under the ./IntegrationServer/packages/ parent directory, and a manifest.v3 file.
An example manifest.v3 file from a freshly created package in webMethods Integration Server 7.1.3 is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<Values version="2.0">
<value name="enabled">yes</value>
<value name="system_package">no</value>
<value name="version">1.0</value>
<null name="startup_services"/>
<null name="shutdown_services"/>
<null name="replication_services"/>
<null name="requires"/>
<null name="listACL"/>
</Values>
A final note: if you take this alternative approach of building your own package creation service, just be careful not to create a new package whose name is considered illegal by webMethods Integration Server.
Related
I have a set of functions defined in a Code Repository (A). Code Repository A has the following structure with my class objectController defined in 'objectController.ts' :
src
index.ts
objectController.ts
How can I use the functions defined in objectController.ts in another Code Repository (B)?
I would actually recommend working within the same Code Repository where possible, but this may in some cases be unavoidable
Steps for setting up the source repository:
Modify package.json to publish the package properly.
Set a new name field to define what the package name should be in other repos. It might make sense to prefix this with something use case specific to avoid conflicts.
Update the main field to "dist/Functions.bundle.js" and the types field to "src/dist/index.d.ts".
(Optional) Set a description.
Commit the package.json changes and publish a tag on this repository.
Validate that the checks pass.
Steps in the destination repository:
Import your source repository.
Go to Settings > Artifacts.
Click + Add
Select your source repository and import it as a backing repository.
Go to package.json. Under dependencies, add the package name you set in the Source repository above (step 1.1), and set the version to the tag that you published (step 2).
Import any exported classes from your package and use them in your code as normal.
Note : You'll have to restart Code Assist after step (2) above in order to have the newly added package show up properly.
Caveats
All code must live in index.ts in the source repository for this to work.
Unit tests in the destination repository that use the imported package will fail. (This may actually be fixable, but I didn't get it to work)
You need to ensure that you have imported all Ontology objects and relations that the source repository relies on into the destination repository.
I also ran into a typing issues in my destination repository.
Error Message:
Errors:
src/index.ts(6,21): error TS7016: Could not find a declaration file for module '{module_name}'. '{redacted}/repo/functions-typescript/node_modules/{module_name}/dist/Functions.bundle.js' implicitly has an 'any' type.
Try `npm install #types/{module_name}` if it exists or add a new declaration (.d.ts) file containing `declare module '{module_name}';`
Solution:
Create a folder called typings.
Create a file within typings called index.d.ts.
Declare the module as shown below in the file created in (2) index.d.ts.
declare module '{module_name}';
Add the path to the file created in (2)index.d.ts in tsconfig.json under the typeRoots element.
"typeRoots": [
"./typings",
"./node_modules/#types/"
]
I am trying to build godoc.org source code in my local to make some changes. My working directory is /Users/Dany/go/src/github.com/golang/gddo. In gddo-server package there several files. One of the go file uses a function from another file which is in the same package but unexported. It is throwing Undefined: <function-name> exception.
Folder is structure is,
golang/gddo/
gddo-server
main.go
crawl.go
How do we use unexported function from the same package in a different file? Could anyone help me with this. Also if anyone has any idea about how to build godoc.org code?
Source files of the same package can refer to identifiers defined in any of the source files without any effort. If they are in the same folder and if they have the same package declaration, you can refer all package-level exported and unexported identifiers as if all would have been defined in one file.
See Spec: Packages:
A package in turn is constructed from one or more source files that together declare constants, types, variables and functions belonging to the package and which are accessible in all files of the same package.
And Spec: Package clause:
A set of files sharing the same PackageName form the implementation of a package. An implementation may require that all source files for a package inhabit the same directory.
One thing to note: your example seems to be the special main package. If you want to run it with go run, you have to enumerate all the source files.
To run your example with go run, navigate to the gddo-server folder and type:
go run background.go browse.go client.go crawl.go graph.go main.go play.go template.go
Or simpler if you first build it. Navigate to the gddo-server folder and type:
go build
This will generate a native executable binary in the same folder. To run it type: gddo-server (on Windows) or ./gddo-server (on Linux).
Or you can install it with go install which will place the result executable binary in your $GOPATH/bin folder.
I want to build all my reports project and copy .rdl files to other location.
I am using MSBuild.Engine for same.
Engine engine = new Engine();
// Point to the path that contains the .NET Framework 2.0 CLR and tools
engine.BinPath = #"c:\windows\microsoft.net\framework\v2.0.50727";
// Instantiate a new FileLogger to generate build log
FileLogger logger = new FileLogger();
// Set the logfile parameter to indicate the log destination
logger.Parameters = #"logfile=C:\temp\build.log";
// Register the logger with the engine
engine.RegisterLogger(logger);
// Build a project file
bool success = engine.BuildProjectFile(#"xyz.rptproj");
//Unregister all loggers to close the log file
engine.UnregisterAllLoggers();
if (success)
Console.WriteLine("Build succeeded.");
else
Console.WriteLine(#"Build failed. View C:\temp\build.log for details");
Also I am getting error that cannot build this project.
Error log says below:
error MSB4041: The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element.
Can someone help or suggest me?
Thanks
This may not be the best answer, but you could create a blank class library project in visual studio, for build and install purposes. Add each RDL file to the project, they can exist on another project so the link (file path in the .csproj) to the file can point to where they actually live on another project in source control. Mark each file as "content" and to "copy always". After that is saved and part of a solution, you can call MSbuild to build that project and use the content output of the build, or this can also be used in an installer to use the content output from the project and specify where you want the install folder to live.
I want to use BIRT to generate reports against data that comes from a JSON based REST API. How can I import this data?
The process for doing this is described at http://developer.actuate.com/community/forum/?app=blog&blogid=45&showentry=471, but it turns out that there are a few important steps missing. I'll fill in a few blanks here.
The original instructions describe creating a Scripted Data Source, with an "open" script that makes use of the com.actuate.json.JSONParser class. First, it is important to realise that this class is not part of BIRT, and needs to be manually added (along with any dependencies).
The download provided by the original instructions provides the com.actuate.json.JSONParser class, but leaves it up to you to source the dependencies. To make things easier I have reimplemented the JSONParser library in Maven, which will then download and package the dependencies for you. It also includes some bug fixes and enhancements like GZIP compression support. You can get the Maven project from https://github.com/mcasperson/birt-jsonparser, and to build the JSONParser library and package the dependencies, run the command
mvn clean package dependency:copy-dependencies
This will result in the birt-jsonparser-0.0.1-SNAPSHOT.jar file being created in the target directory, and all the dependencies copied into the target\dependency directory. Copy all of these JAR files into the {BIRT_INSTALL}/plugins/org.eclipse.birt.report.viewer_{BIRT_VIEWER_VERSION}/birt/scriptlib directory to allow the JSONParser class to be accessed from within your BIRT report.
If you want to debug your report, these JAR files will also have to be referenced in the Debug profile.
I have too many modules (around 90) in my project.
But I want to keep individual displaytag.properties file for each module rather than having single file for whole project.
How to achieve this.
I am using struts2
I think that you can configure each displaytag using the appropiate bundle, remember the bundle search order from S2 docs:
ActionClass.properties Interface.properties
Interface.properties (every interface and sub-interface)
BaseClass.properties (all the way to Object.properties)
ModelDriven's model (if implements ModelDriven), for the model object repeat from 1
package.properties (of the directory where class is located and every parent directory all the way to the root directory)
search up the i18n message key hierarchy itself
global resource properties
and from the docs for the DisplayTag library:
For the whole web application, create a custom properties file named "displaytag.properties" and place it in the application classpath. Displaytag will use the locale of the request object to determine the locale of the property file to use; if the key required does not exist in the specified file, the key will be loaded from a more general property file.
so i guess that the displaytag will search the config keys in the s2 available bundles.