DEV Community: Mariela Dimitrova

🌎 Earth Day Frontend Challenge landing page

Mariela Dimitrova — Thu, 25 Apr 2024 20:41:37 +0000

This is a submission for Frontend Challenge v24.04.17, Glam Up My Markup: Earth Day Celebration Landing Page

What I Built

Let's celebrate Earth Day 2024 together!

This project is a simple landing page that presents the idea behind Earth Day, why it is important to be aware of what is going on in our home, and how to spread that information around the world!

Demo

🌎 Earth Day landing page demo →

🌎 Earth Day GitHub Project →

Journey

I started with the idea of creating a page navigation that facilitates the movement across the page. As an addition to the navigation, I also added a back to top button.

After the navigation, I continued with building each section. I tried to make them fun and catchy but consistent and engaging enough.

MIT License
Copyright (c) [2024] [Mariela Dimitrova]

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
ONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Chocolate CSS devchallenge 🍫

Mariela Dimitrova — Mon, 25 Mar 2024 12:28:51 +0000

This is a submission for DEV Challenge v24.03.20, CSS Art: Favorite Snack.

Inspiration

"Forget love ❤️ ... I'd rather fall in chocolate!"

Demo

See the Pen Chocolate by Mariela (@marielavd) on CodePen.

Journey

I started with the idea to present only a couple of chocolate blocks but then I thought why not a whole chocolate bar. I drew first the chocolate blocks, then I added the package. But this didn't look interesting at all so I continued by adding a missing block (I wish I could eaten it instead 😂) and some leftovers.

The part with the animation was a bit tricky for me since I was not sure how this could be achieved so I did a little digging. Playing around with the CSS @keyframes rules was fun and as of now, I can proudly say I've mastered them.

MIT License
Copyright (c) [2024] [Mariela Dimitrova]

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Webinar: Introducing the new Overall Equipment Efficiency (OEE) App for Software AG Cumulocity IoT

Mariela Dimitrova — Fri, 22 Oct 2021 08:39:27 +0000

The Cumulocity IoT™ Overall Equipment Effectiveness app helps collect and analyze data from sensors in the manufacturing process, from heavy production machinery to painting and finishing. This data is integrated, analyzed and represented as an effectiveness score (a percentage of target). Companies have been able to calculate their OEE for many years, but many of these processes are based on manual data collection and analysis. In many cases reports are produced on a daily basis.

In this event we will present the new OEE app from Software AG which aims to provide reports as frequently as every minute, helping organizations to identify problems or opportunities in time to react effectively to them.

Reserve your spot and join us on November 2 2021, at 14:00 CET

Read full topic

Introducing Software AG Groups – a new home for community events

Mariela Dimitrova — Tue, 19 Oct 2021 09:32:41 +0000

Great news for our community! We are thrilled to announce the availability of Software AG Groups, a new platform for all our community-driven virtual and in-person events – from international and local user groups to developer meetups.

This is the place where people working with Software AG products can get together, stay connected, meet and exchange knowledge. You can easily explore all available groups and join them with a click of a button. Once you join the group, you will be notified by all upcoming events group leaders have planned.

Become a group leader

Around the world, Software AG Groups meet to talk about topics related to webMethods, Cumulocity IoT, Adabas & Natural, ARIS and other Software AG products. Each group has at least one leader who manages the activities and organizes in-person and/or virtual meetups. Software AG supports the group leaders to get the group started and organize events on an ongoing basis.

In case you are interested in co-organizing a group or even starting your own – please reach out to us and apply here: Become a Group leader | Software AG Groups

Read full topic

Lightweight M2M: The Communicator in the Internet of Things

Mariela Dimitrova — Tue, 19 Oct 2021 09:32:30 +0000

Back in February 2017, Gartner predicted there would be around 20.4 billion networked devices worldwide in the Internet of Things (IoT) in 2020. By the year 2025, that number should top 75 billion. But the exact number of devices and sensors isn’t really that important. It’s the trend that suggests companies need to engage with this subject and find their own strategies for a networked organization.

For a technology that gets its name from the internet, astonishingly, the internet only plays one role among several. Why? Because there are a growing number of IoT scenarios with devices that lack a constant internet connection—and even some without a power supply. This edge computing concept enables the intelligent use of data in remote areas that have little or no networking. Furthermore, it takes into consideration the fact that often the internet simply isn’t necessary for immediate actions. For instance, if a sensor detects an elevated temperature in a machine’s coolant fluid, then it can trigger an actuator to shut down the machine immediately. The cloud and thus the internet only come into play as a platform for transmitting data when the goal is to use this machine’s data to enable predictive maintenance or optimized operation through algorithmic evaluation.

Lightweight M2M creates connections

OMA Lightweight M2M (LWM2M) offers a protocol for data connections between machines and the cloud. The open-source protocol from the Open Mobile Alliance is specially designed for devices with limited processing power, consuming very little energy. Many telecom companies use LWM2M, and the lightweight protocol is becoming increasingly popular in the device management market.

LWM2M defines a common language for communication between the edge and IoT platforms in the cloud, such as Cumulocity IoT. The metadata, which describes the individual device functions needed to interpret the transmitted data, is stored in a central repository in the cloud. In this way, LWM2M reduces the data transmission by devices to a minimum. Saving bandwidth, in particular, accelerates data transmission for remote devices and makes it more cost-effective. Moreover, this metadata enables users to connect new device types with an IoT platform quickly and easily without any programming, just with configuration in the web interface. The user manual shows just how easy this is in Cumulocity IoT.

For a more detailed explanation of LWM2M, check out the Software AG Technology Radar.

Let’s look at two different industries showing what a real-world application of LWM2M could look like.

LWM2M in practical application: Smart logistics

Here’s a glance at the logistics industry playing an absolutely critical role in keeping global supply chains up and running. Fleets in particular seldom have a permanent internet connection—and actually, that’s needed only rarely. However, exchanging data between vehicles and the cloud is necessary to share traffic and weather data, for example, or data about routes and deliveries. Vehicle data becomes part of that for maintenance interval notifications. And all of it can be organized and managed with sensors, telematics, and solutions like Cumulocity IoT.

Smart agriculture and water management

Agriculture is another industry with entirely different requirements and challenges, including efficiency problems due to leakage, as it loses between 30% and 50% of the valuable water needed to irrigate livestock, pastures, and fields. With IoT technologies, farmers, as well as water and energy companies, can have real-time insights into the condition of their infrastructures and water supply via networked sensors—enabling them to act immediately when they need to. The networked sensors constantly capture data in the equipment but only send warnings about leaks in acute situations or regulate the water pressure if necessary.

LWM2M connected with sensors on one side and the cloud on the other is very easy to use and—when deploying ready-to-use platforms like Cumulocity IoT—is a highly integrated opportunity for connecting assets with the Internet of Things, making it a technology for the future.

Read full topic

Effective Risk Management with Alfabet – Part 2

Mariela Dimitrova — Tue, 19 Oct 2021 09:31:34 +0000

This is part 2 of our 5-part series on application-based risk management. In part 1, we learned how to prepare a detailed listing of all applications as preparation for setting the scope of the risk assessment. Here, we will discuss the next step which is prioritizing applications in order to focus risk assessment and mitigation efforts on the critical issues.

Prioritize applications

Multiple stakeholders commonly carry out IT risk assessment, involving many objects—applications, processes, technologies, services—and a variety of risks to be assessed. Thus, a clear focus should be set on only the relevant objects. This should be done in two phases. First, identify the most risk-relevant applications—those which are most important to protect—and make them a priority. These will be applications that support business-critical capabilities or are subject to compliance regulations. Second, perform a detailed risk and mitigation survey. The survey is to fine-tune the reasoning for an application being risk-relevant. Using workflows, calculation routines and reporting tools can automate this process and follow-up analyses, thus making it less costly in terms of labor. The answers, for example, “major breach of law” for regulatory risk, can then be mapped to metrics reflecting the type of violation, such as confidentiality, integrity, or availability. These metrics are then added up to provide a risk-relevance score for the application.

Roles:

IT Compliance Manager, CISO

Activities:

Define questions and mappings to metrics
Survey application owners
Decide on prioritization

Deliverables:

List of applications for risk assessment

Best-practice recommendations:

Be pragmatic—pursue a qualitative approach directed at relevant stakeholders
Use only a compact set of questions with simple answers
Map the answers to numeric values for easier analysis

Here is a sample survey of questions to ask for each application:


1. Data and Content	What is the classification of the data and content according to the predefined classification scheme?	- public - internal - confidential - private confidential - strictly confidential - individual-related-public
2. Regulatory	To what extent are laws, regulations, norms or similar applicable? What are the consequences of non-observance?	- no relevance - misdemeanor - minor offense - penalty - major breach of law
3. Contractual Relevance	Are there applicable contractual obligations with customers, suppliers or partners that may result in penalty payments?	- none - up to 10% of contract volume - up to 30% of contract volume - up to 50% of contract volume - in excess of 50% of contract volume
4. Downtime	How long can the service be down without major impact?	- no availability requirements - less than 1 week - less than 1 day - less than 4 hours - less than 1 hours
5. Financial Implications	What is the maximum total damage for the unit under the assumption of a worst-case scenario (including penalty payments, opportunity costs and indemnities?)	- not relevant - less than €500,000 - less than €2.5 million - less than €10 million - more than €10 million - unknown

Figure 1: Here we see a metrics scheme that gives a specific value to each answer depending on which type of protection requirement it would need.

Stay tuned for our next episode on assessing the risks to applications to be able to suggest and evaluate possible mitigations.

Read full topic

The Ultimate Guide to API Versioning

Mariela Dimitrova — Tue, 19 Oct 2021 09:30:44 +0000

Successful software always gets changed.

– Frederick P. Brooks

What is true for software in general, also holds for APIs: successful APIs get changed. The reason is simple: successful APIs are used by various API consumers who demand new features, extensions, bug fixes and optimizations. From this perspective, changes in APIs are inevitable.

But this is only half the story. Successful APIs are used by various API consumers, who rely on the API to remain stable to avoid breaking their existing integrations. Their software clients have dependencies on the API. Even a small change in the API is enough to break some of the clients consuming the API. From this perspective, changes in APIs are undesirable.

Obviously, there is a dilemma. And it is the task of the API provider to resolve this dilemma. In this article, I want to give you some tips for dealing with it. To deal with change and versioning effectively, we need to take a life cycle approach. From the perspective of the API life cycle, we look at the API from its inception and design all the way to its retirement. And I hope it does not come as a surprise to you – but dealing with change is also about being prepared. So you need to start thinking about changes to the API way before the concrete change proposal is appearing on the radar.

We can divide the life cycle of an API into two big phases: the design-time phase before publishing the API and the phase after publishing the API. In these two phases, you need to deal with changes in a very different manner; in fact, when transitioning from one phase to the next, your mindset about change needs to switch 180 degrees.

Before publishing the API

When you initially design an API, you might not even think about future changes. But they will come. So here are three tips on how to support the evolution and versioning of your API already during design time.

Before publishing the API: welcome feedback in iterative API design

Before the API is published, change is great - you need to welcome it and seek it out. Use an iterative development methodology, elicit feedback from beta customers, adapt the API spec based on the feedback you have received on API mocks and beta-versions of the API. This iterative development should ensure that the API you create is actually quite stable, and should reduce the likelihood of immediate future changes. But don’t stop with your API design here and publish the API.

Before publishing the API: prepare an API design pattern for versioning

Create an API design pattern for versioning right from the start when you publish the API for the first time. It might seem superfluous at the time of initial design, but it allows you to roll out consistent versions in the future and sets the right expectation for API consumers. Ideally, the API design pattern for versioning chosen for your API is documented in your API design style guide.

While the most commonly observed pattern is realizing API versioning as the URL path parameter, there are various alternative API design patterns for making major versions accessible:

Realize API versioning in the Accept header: the client can use the HTTP Accept header to explicitly indicate the version of the API. The Accept header still contains the MIME-types as usual, but in addition, the version is appended. The URL of the API does not contain any version information. For new versions, the URL does not change, but the request header.
Realize API versioning as URL path parameter: the most common technique for versioning uses a URL parameter with the version number
Realize API versioning in a custom HTTP header: a custom HTTP header could be defined for the version
Realize API versioning as a query parameter: a query parameter could be defined for the version
Realize API versioning as a new subdomain: a subdomain could be defined for the new version

Before publishing the API: anticipate future change

Anticipate future changes to your API and accommodate for it in your API design. Everyone knows that this is difficult as there are no hard facts about the future. But it is important preparation for the evolution and versioning of your API. Base your assessment on experience and domain knowledge. Maybe you know there is an upcoming industry standard in the domain of the API that needs to be supported. Maybe you know that some scalar data fields will likely need to become an array in the future. The point is to prepare the API spec so that evolution in the anticipated direction is possible without breaking changes.

After publishing the API

After the API has been published, your attitude to change in the API needs to be much more conservative in the interest of your existing API consumers. Change needs to be managed much more rigorously. The basic rule is that the externally observable behavior of an API (from the perspective of the clients) cannot be changed, once the API has been published – and the exception to the rule is: creating a new version of the API.

Managing change – step 0 – is the change really necessary?

First, assess if the proposed change is really necessary. If you can avoid the change: great. One less problem.

Managing change – step 1 – is the change backward compatible?

If the change is really necessary, determine what the change means for the API contract — typically your OpenAPI spec — and for the API consumers relying on the API contract. Ideally, you have an OpenAPI spec for the published API and a new API spec that has all the proposed changes in it. Assess each of the changes and determine whether they are backward compatible or incompatible.

Backward compatible changes:

Adding query parameters (they should always be optional)
Adding header or form parameters as long as they are optional
Adding new fields in JSON or XML data structures as long as they are optional
Adding endpoints, e.g. a new REST resource
Adding operations to an existing endpoint, e.g. when using SOAP
Adding optional fields to the request interfaces
Changing mandatory fields to optional fields in an existing API

Incompatible changes (a.k.a. breaking changes):

Removing or changing data structures, i.e. by changing, removing or redefining fields in the data structure
Removing fields from the request or response (as opposed to making it optional)
Changing a previously optional request field in the body or parameter into a mandatory field
Changing a previously required response field in the body or parameter into an optional field
Changing the URI of the API, such as hostname, port or path
Changing the structure or relationship between request or response fields, e.g. making an existing field a child of some other field
Adding a new mandatory field to the data structure

Managing change – step 2 – dealing with backward compatible changes

If you have found no incompatible changes, only backward compatible ones, you should be able to implement them without breaking clients. Apply semantic versioning and give the API release that covers the changes a new minor version. This new minor version will replace the published API already available. Old clients should not be affected by the changes while new clients can take advantage of the new functionality.

There is one general issue with changes even if they are backward compatible. Backward compatibility is based on the API spec, the OpenAPI specification, which serves as the "official contract” with the API consumer. But Hyrums law tells us that, given enough API consumers, there will be an API consumer relying on any observable behavior of your API, not only on the behavior described in the Open API specification.

Managing change – step 3 – dealing with breaking changes

If you have found at least one incompatible change, it will break clients that rely on the changed feature. A new major version of this API is required, and this new version needs to be maintained in parallel with the previous version. Moreover, major versions need to be visible to the consumers, and they need to be accessible by the consumers. If you have followed this guide from the start, you already have a mechanism in place for picking different versions. See section (Prepare an API design pattern for versioning).

(TODO: alternative - remove: incompatible changes need to be implemented in such a way that existing clients are not affected. This can be accomplished by creating a new major version of the API and maintaining the unchanged API alongside the changed API. Creating and publishing a new version of the API is overhead and thus slows down any changes to the API.)

Managing change – step 4 – sunsetting

Operating and maintaining multiple versions of the API requires a lot of effort on the side of the API provider. Sooner or later, old versions of the API need to get turned off. But this should not be a sudden event, rather a gradual one – like a sunset. That’s why we call this phase the API sunset.

You need to set clear expectations for the API sunset and communicate it as early as possible to all affected API consumers – giving them as much time as possible to deal with the sunset and lift their API clients to the new version of the API. You need to know your API consumers and have a way to contact them, which is typically in place when API consumers need to be onboarded. Get API consumers on a mailing list – not for marketing purposes but for product changes. Send out a targeted message on the mailing list to all API consumers when a new version of the API is published, including a timeline for switching off the old API. Motivate your API consumers to switch to the new version in time and explain the benefits of using the new version.

Conclusion

We have seen that dealing with versioning in APIs starts way before the first breaking change is introduced in an API, and even before the API is initially published. A properly designed API will likely be able to live without breaking changes because it is iteratively designed, future changes have been anticipated and a versioning pattern is defined. And if those changes eventually come, you can categorize the changes in backward compatible and breaking change and react accordingly with minor and major versions and eventual sunsetting of API versions.

About the Author Dr. Matthias Biehl

Matthias empowers customers to discover their opportunities for innovation with APIs & ecosystems and turn them into actionable digital strategies. Based on his experience in leading large-scale API initiatives in both business and technology roles, he shares best practices and provides strategic guidance. Matthias works as an API strategist at Software AG, publishes a blog at API-University, is the author of several books on APIs, and regularly speaks at technology conferences.

Twitter | LinkedIn

Read full topic

New DevBytes videos on webMethods.io Integration, API & B2B

Mariela Dimitrova — Tue, 19 Oct 2021 09:30:17 +0000

Are you a user, developer or architect? Are you trying to build your solution on the cloud? Are you tired of trying to map various available features in the platform with your use cases?

Introducing Software AG’s DevByte series with short descriptive videos focused on use cases and how-to’s. The videos will help you fast-track designing and implementing cloud solutions and in less than five minutes.

The video series is categorized as API DevBytes, B2B DevBytes and webMethods.io Integration Essentials and Advanced tutorials.

webMethods.io DevBytes

webMethods.io API DevBytes can be used as reference videos during webMethods.io API implementation. These training videos are categorized as overview, tutorials, tips and tricks for topics in Product webMethods.io API. Short lectures and demonstrations cover how to create APIs, create policies, SOAP to REST transformation, API Developer Portal configuration, AppMesh etc.

webMethods.io B2B Essential DevBytes

webMethods.io Integration Developer Essentials and Advanced tutorials can be used as reference videos during webMethods.io Integration implementation. These videos contain short lectures and demonstrations that cover how to create workflows, FlowServices, configure connectors, configure APIs, set up hybrid connections, perform OAuth, how to build custom connectors, use reference data, use cache, execute schedulers, parallel processing and many more.

webMethods.io Integration Developer Essentials and Advanced Tutorials

These courses will equip the participants to integrate various enterprise products, create and manage APIs, and create and manage different B2B partners using out of the box features of webMethods.io iPaaS offerings.

Feel free to send us your feedback - your opinion matters to us! Let us know what features and functionality you’d like to see explained in the series – just add your topics in the comments section below. Who knows – your DevByte may come along very soon!

Read full topic

What’s New in Software AG webMethods 10.11 Release

Mariela Dimitrova — Fri, 15 Oct 2021 13:07:48 +0000

Software AG’s webMethods products empower you to build solutions on the top-rated hybrid integration platform and integrate cloud-based apps and on-premises systems without coding, simplify with one toolset for on-premises and cloud integrations and use microservices-style architecture to deliver and scale new integrations faster.

The webMethods suite, with integration and API management products, provides a broad collection of capabilities, including application and partner integration, API management, B2B integration, managed file transfer, building micro-services, high-speed messaging, and in-memory caching. With webMethods, you have an extensible, scalable, and reliable backbone running either in the cloud, on-premises, or hybrid scenarios, providing seamless integration for cloud, mobile, APIs, and Internet of Things (IoT).

Here are some of the new innovations and product updates in the webMethods 10.11 release.

Integration and B2B

webMethods DataHub is an innovative zero-code solution that can extract data flowing through the Integration Server and make it accessible in near real-time in a data lake. Once the data is offloaded in a data lake of customer’s choice, a query engine highly optimized for the data lake usage that has a standard SQL interface can allow BI and AI/ML tools to provide custom dashboards and visual analytics to drive operational analytics and business outcomes.

Creating a docker image of a Microservices Runtime is now supported without the web services functionality. This is useful for deploying microservices where no SOAP processor is required and results in a 50MB reduction in image size and 2-3 seconds improvement in startup time.
Richer monitoring with extended metrics from tools (such as Prometheus) allows layered products that run on top of Microservices Runtime to include additional information.
Importing an Open API 3.0 definition is now supported by Integration Server to generate services that allow a user to call an external API from their services.
Exposing services for use with clients using the gRPC protocol is now supported. This requires that developers first provide a .proto file from which they can generate the necessary document types and service stubs. Integration Server supports the unary gRPC pattern.
Adding PKCE to mitigate the Authorization Code Interception Attack. This is optional and can be configured on a server-wide basis via updates to the OAuth settings in the admin console.
Setting default passwords can now be either set when installing the product or deferred until the first login via the administrative console.
Integration Server now respects FIPS 140-3 security profile, with the ability to drop TLS 1.1 or lower through the extended setting watt.net.jsse.server.disabledProtocols.
Mapping steps in flow services (within the Service Development perspective in Software AG Designer) can take advantage of our machine learning to intelligently map one structure to another. This requires a network connection to connect to Software AG’s Cloud.
Developers can utilize and take advantage of CloudStreams public APIs to enable the integration of CloudStreams with their own applications in a simple and secure manner.
Two-way SSL support in OAuth 2.0 to access token generation flows while configuring a new or existing connection.
Adding, deleting, and viewing certificates and monitoring certificate life cycle for various assets in webMethods Active Transfer UI. Certificates can be automatically migrated from the previous version.
webMethods ActiveTransfer can now be configured to send emails for scenarios such as post-processing and scheduled actions, new user creation, user password changes, and manual file sharing using web clients.
Creating Docker images for a Universal Messaging server on Linux operating systems can be done through Software AG Installer.
Universal Messaging is now backward and forward compatible with the Universal Messaging Java client, JMS, and Resource Adapter.

API Management and Microservices

webMethods Developer Portal features a much simpler and leaner architecture. Developer Portal is a fully API-enabled, headless, and pluggable solution. However, headless does not mean that the Developer Portal is missing the user interface. Though the Developer Portal comes with a fully functional and customizable UI, the API layer offers you the possibility of building a UI of your own. Customers can use the built-in UI if they choose. The Developer Portal 10.11 is functionally equivalent to API Portal 10.7, except for the features to manage apps and download client SDK. Both these features will be implemented in upcoming versions. There is a migration path and a utility to upgrade and migrate API Portal 10.7 instances to Developer Portal 10.11.

API Gateway now allows registering GraphQL APIs and shows the basic details of the API’s query and mutation operations.
Exposing SOAP APIs as REST APIs allows configuring the JSON response payload based on the native service original XML payload and API schema definitions.
An enhanced API Gateway UI that provides visual clues to indicate which API endpoints are currently active for an API.
Additional options for clustering are provided, which simplifies the deployment architecture. API Gateway administrators can now choose between existing Terracotta-based clustering and the new Ignite-based clustering.
New API tracing mode option for API providers.
Increased flexibility in API package and plan definitions.
Enhanced data purging and archiving capabilities allow condition-based purge operations.
APIs deployed to the Microgateways or APIfied microservices in AppMesh can now be activated in the API Gateway for public access.

webMethods Suite Enhancements

The webMethods Suite includes enhancements that improve functionality across multiple products.

webMethods 10.11 ships with Azul JDK 11. Software AG delivers the JDK with its products. Software AG products are tested and supported with this shipped version of JDK.
Software AG Designer is now feature-compatible with Eclipse 4.19 and Azul JDK11.
Software AG Command Central focuses on increasing the server performance when processing many jobs. You can expect significant improvement in the server’s responsiveness and better scalability when working with more SPM nodes.
The classic web user interface of Software AG Command Central now allows bootstrapping Platform Manager based on the registered bootstrap installers in Software AG Command Central.
The enhanced version of the Pre-Upgrade Analyzer now installs as an Integration Server package called WxAnalyzer and includes a simple DSP-based UI.

For more details, please check out the webMethods Release Notes 10.11 on https://documentation.softwareag.com/

Read full topic

webMethods Integration Server Command-line tool Tutorials

Mariela Dimitrova — Fri, 15 Oct 2021 07:13:59 +0000

Overview:

Administer webMethods Integration Server from your Linux or DOS shell. Use the command line to view and modify Integration Server configuration and perform dozens of administrative actions.

Playlist:

Read full topic

Administer Integration Server from the command line

Mariela Dimitrova — Thu, 14 Oct 2021 13:04:28 +0000

This post introduces a command-line utility for administering webMethods Integration Server. It’s not an official Software AG product and is not supported, but you may find it useful. The tool is written in node.js and can be viewed at https://www.npmjs.com/package/@softwareag/wmisa.

To get started

Install node.js from https://nodejs.org/
Install the tool with npm i @softwareag/wmisa
Explore

        wmisa -h view usage information
        wmisa info view tool help
        wmisa help view all the admin resources on the server
        wmisa help resource-type view all the operations for a resource
        wmisa help operation view the inputs and outputs for a resource operation

There is a series of short Youtube videos explaining how to use the tool:

PART 1 - Installation and getting help
PART 2 - Viewing administrative resources
PART 3 - Modifying administrative resources
PART 4 - Command-line options and setting defaults

The tool is wmisa , for webMethods Integration Server administration. It talks to IS’s Administrative API. Pretty much any operation you can do with the API can be executed from the command-line tool, with just a few exceptions.

This tool was a bit of a side project for me; a chance to get some exposure to node.js and make something useful for the community. It’s a bit rough around the edges. Unfortunately we are not able to support it at this time. We intend to put it on GitHub and let others improve it. That said, I think it will be useful in a scripting/devops environment. Here are a few of the many things you can do with this utility.

wmisa read keystore

Get a list of the server’s keystore aliases.

wmisa start cachemanager WarehouseStore

Start the cache manager named WarehouseStore.

wmisa create user --file newuser.json

Create a new user account. The file newuser.json contains the payload:

{
      "username": "tomasso",
      "groups": ["IT_Managers", "IT_Rome", "Everybody"],
      "enabled": true,
      "password": "ChangeThis",
      "allowDigestAuth": false
}

wmisa --host vmcambit01:5543 --secure update port https InternalAdmin --file portupdate.json

Update an HTTPS port with the alias InternalAdmin on vmcambit01:5543. Use TLS. The portupdate.json file contains the payload

{
     "keepAliveTimeout": 20000,
     "backlog": 300
}

wmisa --host vluxvm001.fr.mdd.org:9001 --basicauth TonyAdmin:MyS3cr3T! quiesce server

Quiesce the server at vluxvm001.fr.mdd.org:9001 using the account TonyAdmin.

Cheers,

Michael

Read full topic

Software AG webMethods.io API Devbytes training videos

Mariela Dimitrova — Fri, 08 Oct 2021 13:47:57 +0000

Overview:

These training videos are categorized as overviews, tutorials, and tips & tricks for topics in webMethods.io API. This training also demonstrates advanced concepts of webMethods.io API.

Playlist:

Read full topic